API and Wiki mprovements

[frspin]

For better integration in alternative GUI programs there are some API and wiki improvements suggested:

For messages:

A more specific message when a new message is arrived instead of the generic "message-db: changed" An API for getting message by call and not only by ID as now An API for resend a message, as: POST 7freedata/messages/{id}/resend

For Wiki:

A more complete info on sending message, with attach (one or more attach) examples An info on body encode('utf-8') requirement An info on delay of 2 seconds for radio frequency update

Regards

Franco Spinelli IW2DHW

[DJ2LS]

@LA3QMA could you do me the favour and working on the wiki parts.

[LA3QMA]

Have updated some information. Not happy with the layout so i'll guess i update the information first and later re-design it. I'll add more examples etc

[DJ2LS]

@frspin how should the "get by callsign" api endpoint act? We can add an endpoint, which is getting all messages, filtered by a callsign, but the question is then, how should we sort them? Means, should we search only for "destination", or "origin", or "destination and origin", which probably mixes then data result.

[frspin]

Il 22/05/24 11:55, DJ2LS ha scritto:

@frspin https://github.com/frspin how should the "get by callsign" api endpoint act? We can add an endpoint, which is getting all messages, filtered by a callsign, but the question is then, how should we sort them? Means, should we search only for "destination", or "origin", or "destination and origin", which probably mixes then data result.

In my opinion an endpoint as

/freedata/messages/{call}

need to get all messages sent or received by/to {call} ordered by time

In each message there is "origin" or "destination" for select if message is "to" call or "from" call

Franco Spinelli

[DJ2LS]

I would suggest something like this:

/freedata/messages/{call}

or what about adding a filter, like

/freedata/messages?byCall={callsign}

/freedata/messages?byCall={callsign}&direction={to/from}

/freedata/messages?byID={message-id}

This would simplify the endpoints.

[frspin]

Il 22/05/24 16:06, DJ2LS ha scritto:

I would suggest something like this:

/freedata/messages/{call}

or what about adding a filter, like

|/freedata/messages?byCall={callsign}|

|/freedata/messages?byCall={callsign}&direction={to/from}|

|/freedata/messages?byID={message-id}|

This would simplify the endpoints.

All are OK but, if you prefer also "direction" please make a default for both

Franco Spinelli

[DJ2LS]

No filter for direction would fetch all directions Von meinem iPhone gesendetAm 22.05.2024 um 16:51 schrieb frspin @.***>: Il 22/05/24 16:06, DJ2LS ha scritto:

I would suggest something like this:

/freedata/messages/{call}

or what about adding a filter, like

|/freedata/messages?byCall={callsign}|

|/freedata/messages?byCall={callsign}&direction={to/from}|

|/freedata/messages?byID={message-id}|

This would simplify the endpoints.

All are OK but, if you prefer also "direction" please make a default for both

Franco Spinelli

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[frspin]

Il 22/05/24 17:03, DJ2LS ha scritto:

No filter for direction would fetch all directions Von meinem iPhone

OK

Franco Spinelli IW2DHW

[DJ2LS]

We are just trying to publish a new release. So we can add this one to the next release I think. Von meinem iPhone gesendetAm 22.05.2024 um 17:15 schrieb frspin @.***>: Il 22/05/24 17:03, DJ2LS ha scritto:

No filter for direction would fetch all directions Von meinem iPhone

OK

Franco Spinelli IW2DHW

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[frspin]

Il 22/05/24 17:32, DJ2LS ha scritto:

We are just trying to publish a new release. So we can add this one to the next release I think.

Thanks

This improvement permit to recall only messages for current call in chat Gui when a "message db changed" event is emitted.

Franco Spinelli IW2DHW

[DJ2LS]

I'm working on this in "dev-filter-messages"

Possible filters:

        filters = {
            'id': request.args.get('id', default=None, type=str),
            'callsign': request.args.get('callsign', default=None, type=str),
            'origin_callsign': request.args.get('origin_callsign', default=None, type=str),
            'via_callsign': request.args.get('via_callsign', default=None, type=str),
            'destination_callsign': request.args.get('destination_callsign', default=None, type=str),
            'direction': request.args.get('direction', default=None, type=str)
        }

example filter: http://127.0.0.1:5000/freedata/messages?id=AA1AAA-1_AA1AAA-1_2024-05-14T15:31:27.879225

[DJ2LS]

   def freedata_message_db_change(self, message_id=None):
        self.broadcast({"message-db": "changed", "message_id": message_id})
        

has been updated as well, the change event contains now the corresponding message id

[DJ2LS]

retransmit message now with: PATCH: /freedata/messages/{id}/retransmit

set message as read: PATCH: /freedata/messages/{id} --> payload: "is_read: True"

where the last one is a endpoint for modifying every message content

[frspin]

Il 25/05/24 10:40, DJ2LS ha scritto:

retransmit message now with: |PATCH: /freedata/messages/{id}/retransmit |

set message as read: |PATCH: /freedata/messages/{id} --> payload: "is_read: True"|

where the last one is a endpoint for modifying every message content

So a PATCH command for this URL.

When in develop branch with filters and new "message-db":"changed" with "message-id" ?

Franco Spinelli IW2DHW

[DJ2LS]

Yes, because we are updating the message data, so „PATCH“ is correct in terms of restAPI.Also yes, the message is will be attached to the change event now. Von meinem iPhone gesendetAm 25.05.2024 um 11:35 schrieb frspin @.***>: Il 25/05/24 10:40, DJ2LS ha scritto:

retransmit message now with: |PATCH: /freedata/messages/{id}/retransmit |

set message as read: |PATCH: /freedata/messages/{id} --> payload: "is_read: True"|

where the last one is a endpoint for modifying every message content

So a PATCH command for this URL.

When in develop branch with filters and new "message-db":"changed" with "message-id" ?

Franco Spinelli IW2DHW

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[DJ2LS]

@ @frspin please give us a 'go' if we can merge this into develop branch. Let us also know, if there are more things to change.

[frspin]

Il 25/05/24 12:30, DJ2LS ha scritto:

@ @frspin https://github.com/frspin please give us a 'go' if we can merge this into develop branch. Let us also know, if there are more things to change.

Yes, merge in develop branch and I am ready to test API changes and report here.

Thanks

Franco Spinelli IW2DHW

[DJ2LS]

I want to merge as soon as we've finished most of the work here so we are not breaking too much things. Do you have some more topics which should be implemented?

[frspin]

Il 25/05/24 16:32, DJ2LS ha scritto:

I want to merge as soon as we've finished most of the work here so we are not breaking too much things. Do you have some more topics which should be implemented?

Not for now.

Franco Spinelli IW2DHW

[DJ2LS]

Okay I'm merging then and closing this issue then.

@LA3QMA now it's up to you 🙂

[frspin]

Il 25/05/24 16:59, DJ2LS ha scritto:

Okay I'm merging then and closing this issue then.

@LA3QMA https://github.com/LA3QMA now it's up to you 🙂

So, according to previous email and from what I can see in modem source now there are:

• new event message when a new message come in database

"message-db":"changed","message-id":[id]

• new API for getting message

/freedata/messages?id=[id]|callsign=[call]|origin_callsign=[call]|via_callsign=[call]|destination_callsign=[call]|direction=[direction]

• new API for modify message

PATCH /freedata/messages/[id] with new message body

• new API for resend message

PATCH /freedata/messages/[id]/resend

Is this correct?

If this is correct I can test filter for getting message by call and new API for resend a message in my test GUI With more work I can test also new event message.

From source code (message_system_db_manager.py) and from database structure I can see there is a table with all calls in database message. An API for getting all calls can be useful for setup of call list at Gui startup. Without this API now a Gui developer is required to get all messages, extract call from each message and assemble call list.

Regards

Franco Spinelli IW2DHW

[DJ2LS]

The Callsign table contains all callsigns ever received - not just the ones for existing conversations.

So what do you specifically need? All callsigns or conversations?

[frspin]

Il 26/05/24 12:48, DJ2LS ha scritto:

The Callsign table contains all callsigns ever received - not just the ones for existing conversations.

Ok, so this is unrelated to messages

So what do you specifically need? All callsigns or conversations?

At startup there is necessity to get all callsign present in messages. For now I get all messages, extract call from every message and fill a list of unique calls.

URL = self.BASE_URL + 'freedata/messages' r = requests.get(URL) jmsg = r.json() messaggi = jmsg['messages']

loop for all messages for get a list of calls who have sended messages

for msg in messaggi: # get calls from when we have received or to when we have send direction = msg['direction'] if direction == 'receive': call = msg['origin'] if direction == 'transmit': call = msg['destination'] if call in self.msg_call: # if call is already in self.msg_call do nothing pass else: # insert call in msg_call self.msg_call.append(call)

I can live with this (it is done only at startup).

Regards

Franco Spinelli IW2DHW

— Reply to this email directly, view it on GitHub https://github.com/DJ2LS/FreeDATA/issues/703#issuecomment-2132173843, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZJWG2UESBZR2ZYIZUGBYLZEG4ZBAVCNFSM6AAAAABGFIR7QKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGE3TGOBUGM. You are receiving this because you were mentioned.Message ID: @.***>

[DJ2LS]

We could add all callsigns to the header when receiving all messages if that's helping 🤔 , say a dictionary with all unique callsigns / conversations, next to "total"

I want to have not too much api endpoints because of complexity

[frspin]

Il 26/05/24 13:49, DJ2LS ha scritto:

We could add all callsigns to the header when receiving all messages if that's helping 🤔 , say a dictionary with all unique callsigns / conversations, next to "total"

I want to have not too much api endpoints because of complexity

For reducing complexity leave as is endpoint "/freedata/messages".

I select unique callsign from messages only at startup and, for normal usage, this is not a problem. It can be a problem when database increase its dimension (many messages from/to many call) but, in this case, also dictionary with all unique callsign can be very big.

Franco Spinelli IW2DHW

[DJ2LS]

Franco, you could use a „set“: 5. Data Structuresdocs.python.orgVon meinem iPhone gesendetAm 26.05.2024 um 13:56 schrieb frspin @.***>: Il 26/05/24 13:49, DJ2LS ha scritto:

We could add all callsigns to the header when receiving all messages if that's helping 🤔 , say a dictionary with all unique callsigns / conversations, next to "total"

I want to have not too much api endpoints because of complexity

For reducing complexity leave as is endpoint "/freedata/messages".

I select unique callsign from messages only at startup and, for normal usage, this is not a problem. It can be a problem when database increase its dimension (many messages from/to many call) but, in this case, also dictionary with all unique callsign can be very big.

Franco Spinelli IW2DHW

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[frspin]

Il 26/05/24 15:17, DJ2LS ha scritto:

Franco, you could use a „set“: 5. Data Structuresdocs.python.orgVon meinem iPhone gesendetAm 26.05.2024 um 13:56 schrieb frspin @.***>:

Thanks for the suggestion.

But, for filling also Gtk.ListBox I think a list structure is more correct.

Franco Spinelli IW2DHW

[frspin]

Il 26/05/24 15:17, DJ2LS ha scritto:

Franco, you could use a „set“: 5. Data Structuresdocs.python.orgVon meinem iPhone gesendetAm 26.05.2024 um 13:56 schrieb frspin @.***>:

Some problems when testing new filter options on messages:

If using old /freedata/messages/[id] syntax I get as response to requests.json() a and not a as previous.

If using new /freedata/messages?id=[id] syntax I get a list of messages but [id] is unique and there is only one message for an ID

What is correct usage of API for getting a message with [id]?

Regards

Franco Spinelli

[DJ2LS]

Is this feature request still up to date? Or did we implement everything in 0.16.0?

[frspin]

Il 05/06/24 10:55, DJ2LS ha scritto:

Is this feature request still up to date? Or did we implement everything in 0.16.0?

Messages improvements are all done in "develop" branch and can be inserted in 0.16 version.

Wiki improvements are all "to do" but can be done with 0.16 version, with documentation of API change.

Franco Spinelli IW2DHW