Open frspin opened 2 months ago
@LA3QMA could you do me the favour and working on the wiki parts.
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
@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.
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
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.
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
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: @.***>
Il 22/05/24 17:03, DJ2LS ha scritto:
No filter for direction would fetch all directions Von meinem iPhone
OK
Franco Spinelli IW2DHW
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: @.***>
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
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
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
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
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
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: @.***>
@ @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.
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
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?
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
Okay I'm merging then and closing this issue then.
@LA3QMA now it's up to you 🙂
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:
"message-db":"changed","message-id":[id]
/freedata/messages?id=[id]|callsign=[call]|origin_callsign=[call]|via_callsign=[call]|destination_callsign=[call]|direction=[direction]
PATCH /freedata/messages/[id] with new message body
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
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?
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']
for msg in messaggi:
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: @.***>
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
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
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: @.***>
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
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
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
Is this feature request still up to date? Or did we implement everything in 0.16.0?
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
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