| freemangordon | dsc_: is it conversations that fills the db or eds tp plugin? | 07:24 |
|---|---|---|
| freemangordon | also, please LMK when you want to start with abook integration, so I can start working on abook<->qt integration | 07:26 |
| dsc_ | freemangordon: incoming messages are inserted by conversations into rtcom db | 14:19 |
| dsc_ | or just messages in general | 14:20 |
| dsc_ | for contact list (roster), it is not saved in rtcom but in `state.json` which is kinda like a cache | 14:20 |
| dsc_ | its just contacts | 14:20 |
| Wizzup | dsc_: I do have questions about this | 14:45 |
| Wizzup | the saving of the contact roster | 14:45 |
| Wizzup | I think we have this in abook/eds, so I don't think we need to save it elsewhere | 14:45 |
| dsc_ | you can think of it as "not being saved anywhere" :D | 14:57 |
| dsc_ | the reason I put them in cache is because | 14:59 |
| dsc_ | when you go online | 14:59 |
| dsc_ | you get a roster | 14:59 |
| dsc_ | so you may get 500 new entries in the overview | 14:59 |
| dsc_ | and pushes the normal stuff down | 15:00 |
| dsc_ | each time | 15:00 |
| Wizzup | I don't really understand this, but I suspect when I start looking at it I will | 15:00 |
| dsc_ | when its in cache, its attached to a date | 15:00 |
| dsc_ | so the overview doesnt get spammed | 15:00 |
| Wizzup | the contacts roster should be entirely tp/eds managed, and we just query it when we need it | 15:00 |
| dsc_ | well you are replying while I didnt even finish explaining | 15:00 |
| dsc_ | re-read what I said | 15:01 |
| Wizzup | I did read it, I don't understand how contact lists/rosters affect the chats overview | 15:01 |
| dsc_ | contacts show up in the overview | 15:01 |
| Wizzup | wait, since when? | 15:01 |
| dsc_ | since every chat application does? | 15:02 |
| dsc_ | https://plak.infrapuin.nl/selif/s5lqdemv.png | 15:02 |
| Wizzup | we have the Contacts application for this | 15:02 |
| Wizzup | but what we lacked was handling of invites and adding contacts/buddies, so that's good to have, but I don't think we need an additional contacts overview | 15:04 |
| dsc_ | https://plak.infrapuin.nl/selif/823mkq66.png | 15:05 |
| dsc_ | they show as messages (empty) | 15:05 |
| dsc_ | but ehh | 15:06 |
| dsc_ | ill check if its possible | 15:09 |
| dsc_ | because......... | 15:11 |
| dsc_ | I need to open channels to these contacts to do any kind of presence stuff | 15:12 |
| dsc_ | but ill verify that | 15:12 |
| dsc_ | e.g I cannot receive an invitation if I didnt instance a contact | 15:13 |
| dsc_ | instancing a contact creates an entry, etc. | 15:13 |
| dsc_ | "receiving an invitation" is one of the many "states" a presence publication can be in | 15:16 |
| dsc_ | presence publication request* | 15:17 |
| dsc_ | but yeah ill check... | 15:17 |
| sicelo | 16:02 < dsc_> since every chat application does? <<--- gajim and friends, yes, because there's no specialized contact management application. but on 'integrated' systems, e.g. even android, then yes, as Wizzup says, contact management is in contact application | 15:17 |
| sicelo | dsc_: nice work btw | 15:20 |
| dsc_ | sicelo: yeah, true. but imo maybe not comparable as conversations is not managing the contacts (well, only accepting friend requests), its just caching stuff for display/UX purposes | 15:21 |
| dsc_ | but I do agree that, if there is a dedicated addressbook, the contacts should be shown there | 15:21 |
| dsc_ | so I shall remove the automatic filling from conversations | 15:25 |
| Wizzup | 15:13 < dsc_> e.g I cannot receive an invitation if I didnt instance a contact | 15:32 |
| Wizzup | yes, that we'll have to do for sure | 15:32 |
| dsc_ | sure | 15:33 |
| freemangordon | you can get contact list from abook | 15:35 |
| freemangordon | no need to manage you own addressbook | 15:35 |
| freemangordon | jut tell me what exactly do you need | 15:36 |
| freemangordon | and I'll provide you the code | 15:36 |
| freemangordon | but, as Wizzup said, rosters etc are matter of eds/tp/abook | 15:37 |
| dsc_ | Telepathy has Tp::ContactManager for the roster | 15:37 |
| freemangordon | lemme check it | 15:37 |
| dsc_ | by asking for contacts, you can check if there are pending invites | 15:37 |
| dsc_ | if this logic is on the addressbook side, then addressbook needs to signal such invites to me somehow | 15:37 |
| freemangordon | gimme a minute to check what this class is doing | 15:38 |
| dsc_ | so this is why I think conversations needs to implement the ContactManager | 15:38 |
| dsc_ | ok | 15:38 |
| dsc_ | next to invites, there's also presence "user is away" | 15:39 |
| freemangordon | so, why do you need from a contact? | 15:40 |
| freemangordon | s/why/what | 15:40 |
| dsc_ | management of buddy list (allow/reject/block/remove), status (online/away), status message | 15:41 |
| dsc_ | I have this currently | 15:41 |
| dsc_ | we can move it to addressbook | 15:41 |
| freemangordon | online status is already implemented in abook | 15:41 |
| dsc_ | sure, abook is just another tp client | 15:42 |
| freemangordon | no | 15:42 |
| freemangordon | it is not "just another tp client" | 15:42 |
| dsc_ | ? | 15:43 |
| freemangordon | as it integrates eds with tp (and few more things) | 15:43 |
| freemangordon | evolution data server | 15:43 |
| freemangordon | with telepathy | 15:43 |
| dsc_ | which does what? | 15:43 |
| freemangordon | EDS is contacts (system addressbook) | 15:43 |
| freemangordon | telepathy is presence/rosters | 15:44 |
| dsc_ | yes? | 15:44 |
| dsc_ | so it listens to Tp | 15:44 |
| freemangordon | I am not sure how is contact blocking done in fremantle | 15:44 |
| freemangordon | sure | 15:44 |
| dsc_ | conversations and abook are both tp clients, now we can move some logic to abook but this is a architecture decision | 15:44 |
| freemangordon | but, it already provides interfaces/classes like avatar and contact online status | 15:45 |
| freemangordon | no, no, it is not that simple | 15:45 |
| dsc_ | in theory they can both listen to presence for example | 15:45 |
| freemangordon | wait | 15:45 |
| freemangordon | roster contact can be attached to master contact | 15:45 |
| dsc_ | right | 15:46 |
| dsc_ | ok | 15:46 |
| freemangordon | so, your GF (lets call it Lara) has master contact in addressbook, with few IM accounts connected to it | 15:46 |
| dsc_ | i have no gf 😠| 15:46 |
| freemangordon | boyfriend the, does not matter :p | 15:46 |
| freemangordon | *then | 15:46 |
| dsc_ | LOL | 15:47 |
| dsc_ | yeah but I get it | 15:47 |
| freemangordon | so, when you receive a message from iamlara@jabber.com, you don't want to show her name/nick on jabbaer.com, but the name that's on master contact in addressbook | 15:47 |
| freemangordon | you can't do that with TP | 15:48 |
| dsc_ | ok | 15:49 |
| freemangordon | you must use OssoABookContact | 15:49 |
| dsc_ | #include <libosso-abook/osso-abook.h> | 15:49 |
| dsc_ | ok | 15:49 |
| freemangordon | wait | 15:49 |
| freemangordon | look at https://github.com/maemo-leste/osso-abook/blob/master/lib/osso-abook-aggregator.h | 15:52 |
| dsc_ | what version of Perl is this? | 15:52 |
| freemangordon | perl? | 15:52 |
| dsc_ | sorry ill stop trolling | 15:52 |
| dsc_ | so ok | 15:53 |
| dsc_ | I can ask for status, online | 15:53 |
| dsc_ | thats fine | 15:53 |
| dsc_ | but the invites | 15:53 |
| dsc_ | this would be handled by conversations, yes? | 15:53 |
| freemangordon | remote invites? | 15:53 |
| freemangordon | and auth requests? | 15:53 |
| dsc_ | in XMPP the correct term is "presence subscriptions" | 15:53 |
| dsc_ | they are bi-directional | 15:54 |
| freemangordon | mhm | 15:54 |
| dsc_ | "user X has asked to see your status" | 15:54 |
| dsc_ | its basically a "buddy invite" | 15:54 |
| freemangordon | so yes, I think conversations should handle that | 15:54 |
| freemangordon | Wizzup: ^^^ correct? | 15:54 |
| sicelo | it's handled by Contacts iirc | 15:54 |
| freemangordon | I am not sure | 15:54 |
| Wizzup | I don't think it is handled by contacts in fremantle | 15:54 |
| freemangordon | right, I think it is handled by conversations | 15:55 |
| Wizzup | my vote would be to handle it in conversations, but fmg and I also discussed whether that should be its own standalone program (I think not for now due to lack of work involved and further complexity) | 15:55 |
| sicelo | i haven't played with this stuff recently on fremantle, but iirc it was Contacts, so that when you accept, a contact is saved | 15:55 |
| Wizzup | if it was handled by contacts I think it would work now :P | 15:55 |
| freemangordon | saving a contact might be a side-effect | 15:55 |
| freemangordon | sicelo: I don;t remember seeing anything "invite" related in abook/addressbook code | 15:56 |
| dsc_ | I ask this, because in order to receive such invites, I need to implement the ContactManager | 15:56 |
| dsc_ | which means maintaining a roster | 15:57 |
| dsc_ | and it sounds like abook is already doing that anyway | 15:57 |
| freemangordon | I still don;t get it why you need a roster | 15:57 |
| freemangordon | like, what this roster is used for? | 15:58 |
| freemangordon | osso_abook_aggregator_find_contacts_for_im_contact() should do some job I guess | 15:59 |
| freemangordon | also, there is OssoABookRosterManager | 15:59 |
| dsc_ | so I would iterate this OssoABookROster | 16:00 |
| dsc_ | to check for invites | 16:00 |
| freemangordon | what for? | 16:00 |
| freemangordon | wait, there is no signal? | 16:00 |
| dsc_ | how does conversations know that there is an invite? | 16:00 |
| freemangordon | there must be dbus signal | 16:00 |
| freemangordon | lemme check tp specs | 16:00 |
| dsc_ | wait | 16:00 |
| dsc_ | if conversations is open, and listening to such signals, then yes | 16:01 |
| dsc_ | if droid4 is powered off | 16:01 |
| dsc_ | and someone sends you an invite | 16:01 |
| dsc_ | then there is no signal | 16:01 |
| dsc_ | so then you iterate the roster | 16:01 |
| dsc_ | and check for the invite | 16:01 |
| dsc_ | when you go online | 16:01 |
| freemangordon | so, server does not queue those? | 16:01 |
| freemangordon | I don't believe that :) | 16:01 |
| dsc_ | sorry it does | 16:02 |
| dsc_ | its just that it doesnt send it multiple times | 16:02 |
| dsc_ | so you cannot rely on signal alone | 16:02 |
| freemangordon | if you are offline, whom it is send the first time? | 16:02 |
| dsc_ | when you go line, you'll receive it. Then you poweroff droid4, go back online, the server wont send this invite | 16:03 |
| dsc_ | online* | 16:03 |
| freemangordon | sure, but you receive it at least once | 16:03 |
| dsc_ | yes | 16:03 |
| freemangordon | so, it is a matter of storing that somehow | 16:03 |
| dsc_ | no | 16:03 |
| freemangordon | why? | 16:04 |
| dsc_ | because the remote can decline that invite in the meantime | 16:04 |
| dsc_ | or remove it | 16:04 |
| dsc_ | remote is source of truth | 16:04 |
| freemangordon | but you'll receive a signal for that too,no? | 16:04 |
| freemangordon | also, how is that different to : | 16:04 |
| dsc_ | hmm | 16:04 |
| freemangordon | you receive a signal for invite and while navigating through the iface this invite is removed | 16:05 |
| dsc_ | what about multiple clients :) | 16:05 |
| freemangordon | ah, you mean if you decline on another device | 16:05 |
| dsc_ | yes, this is why it cannot be stored, I think | 16:05 |
| dsc_ | but I would assume abook already has such logic, no? | 16:06 |
| freemangordon | but ok, if you have multiple devices, then what? all of them receive the signal, no? | 16:06 |
| freemangordon | abook has nothing to do with invites | 16:06 |
| dsc_ | abook maintains a roster | 16:06 |
| dsc_ | eh, it asks for a roster | 16:06 |
| freemangordon | no, server maintains a roster | 16:07 |
| freemangordon | yeah | 16:07 |
| dsc_ | yes :P | 16:07 |
| freemangordon | actually it is not abook | 16:07 |
| freemangordon | but eds plugin | 16:07 |
| dsc_ | and within this roster, contacts have a "publication status" | 16:07 |
| freemangordon | that creates EBook | 16:07 |
| freemangordon | no | 16:07 |
| freemangordon | but we can add, if needed | 16:07 |
| dsc_ | i dont know if abook does this, yeah | 16:07 |
| freemangordon | sec, lemme check something | 16:08 |
| dsc_ | for example, with XMPP you cannot see someone's online status without a friend request | 16:08 |
| freemangordon | yeah, we have it | 16:08 |
| dsc_ | you have to accept eachothers status publication request | 16:08 |
| dsc_ | ok | 16:08 |
| freemangordon | see https://github.com/maemo-leste/osso-abook/blob/master/lib/osso-abook-contact.h#L87 | 16:09 |
| freemangordon | "X-TELEPATHY-BLOCKED", "X-TELEPATHY-SUBSCRIBED", "X-TELEPATHY-PUBLISHED" | 16:09 |
| dsc_ | yes | 16:09 |
| dsc_ | thats it | 16:09 |
| freemangordon | sec, to see how are those mapped | 16:10 |
| freemangordon | see https://github.com/maemo-leste/eds-backend-telepathy/blob/master/src/e-book-backend-tp-contact.c#L209 | 16:11 |
| freemangordon | hmm, I don;t see eds plugin setting those | 16:13 |
| freemangordon | perhaps I just don;t see it, lemme dig deeper | 16:15 |
| dsc_ | so from osso I will need | 16:15 |
| dsc_ | these friend requests | 16:16 |
| dsc_ | per Tp account | 16:16 |
| dsc_ | and you're saying I can iterate contacts through the osso API | 16:17 |
| dsc_ | which will give me those statuses | 16:17 |
| dsc_ | yeah its fine by me | 16:17 |
| freemangordon | yeah, according to the theory | 16:18 |
| freemangordon | perhaps you already have the requests as well | 16:18 |
| freemangordon | but I am checking what data is attached | 16:18 |
| freemangordon | ok, I guess the magic happens here https://github.com/maemo-leste/eds-backend-telepathy/blob/master/src/e-book-backend-tp-cl.c#L691 | 16:21 |
| dsc_ | yes, I think it has this logic for pending, etc. | 16:23 |
| freemangordon | mhm | 16:23 |
| freemangordon | but, should do some tests to see how it appears in the vcard | 16:23 |
| dsc_ | this is very similar to my C++ for contactChanged | 16:23 |
| freemangordon | sure, qt api is just a wrapper on top of glib | 16:24 |
| freemangordon | glib api that is | 16:24 |
| freemangordon | this is Perl 3.17 | 16:24 |
| freemangordon | lemme chek how tp-glib reports invites | 16:25 |
| freemangordon | dsc_: what about https://telepathy.freedesktop.org/doc/telepathy-glib-0.24.x/telepathy-glib-contact.html#TpContact--publish-request? | 16:26 |
| freemangordon | does it look familiar? | 16:26 |
| dsc_ | yes | 16:26 |
| freemangordon | ok, lemme see if eds plugin cares about that | 16:27 |
| dsc_ | that's fine | 16:27 |
| dsc_ | as long as I can get these properties | 16:27 |
| freemangordon | if it is missing, I can easily add it | 16:28 |
| freemangordon | no need to duplicate code | 16:28 |
| freemangordon | but will need some time to see what happens | 16:29 |
| freemangordon | dsc_: hmm, you know what? you get tp handle from abook rosters list | 16:30 |
| freemangordon | so I think you can create contact from that handle and ask it whatever you want | 16:31 |
| dsc_ | ah thats nice | 16:31 |
| freemangordon | lemme check the api | 16:31 |
| freemangordon | oh | 16:33 |
| freemangordon | osso_abook_contact_get_blocked() :) | 16:34 |
| dsc_ | can_block, can_request_auth, reject_for_uid | 16:35 |
| dsc_ | so that looks OK | 16:36 |
| freemangordon | yeah, looks like that;s itr | 16:36 |
| freemangordon | not sure that works though | 16:36 |
| freemangordon | in leste that is :) | 16:36 |
| freemangordon | never been used | 16:36 |
| dsc_ | yes | 16:36 |
| dsc_ | but I rather have this in abook | 16:36 |
| freemangordon | right | 16:37 |
| dsc_ | because for me its much easier to use this API | 16:37 |
| freemangordon | sure | 16:37 |
| freemangordon | that's the point :) | 16:37 |
| freemangordon | despite being C | 16:37 |
| dsc_ | I have implemented in c++ right now | 16:38 |
| dsc_ | i was about to make a PR | 16:38 |
| freemangordon | a pity | 16:38 |
| dsc_ | doesnt matter | 16:38 |
| dsc_ | well | 16:38 |
| dsc_ | i lost 10 days | 16:38 |
| freemangordon | yeah, that's why "a pity" | 16:38 |
| freemangordon | ok, I a running out of time now (guests are coming), will ping you tomorrow to see what exactly do you need in terms of functions etc | 16:40 |
| dsc_ | alright | 16:40 |
| dsc_ | thanks | 16:40 |
| freemangordon | might even create a test qt app that calls abook | 16:40 |
| freemangordon | and gives you the status of app contacts in an account | 16:40 |
| dsc_ | in the meantime ill try some things | 16:41 |
| freemangordon | ok, see test applications in abook | 16:41 |
| freemangordon | like this https://github.com/maemo-leste/osso-abook/blob/master/lib/test-contact-chooser.c | 16:41 |
| freemangordon | keep in mind aggregator/roster/etc are of type OssoABookWaitable | 16:43 |
| freemangordon | see https://github.com/maemo-leste/osso-abook/blob/master/lib/osso-abook-waitable.h | 16:43 |
| freemangordon | you will need osso_abook_waitable_call_when_ready() most probably | 16:43 |
| dsc_ | does this influence the Qt eventloop? | 16:48 |
| freemangordon | qt evenloop uses GMainLoop on linux :) | 16:53 |
| freemangordon | so you should not do anything special (in theory) | 16:53 |
| dsc_ | alright | 16:53 |
| arno11 | finally i'm not sure if a web browser is so important on N900 in 2024...with chatgpt-4 working fine on it and able (for example) to write/build its own gtk UI for my device. another world | 23:35 |
| arno11 | i think we can make funny/crazy things with it on Leste | 23:37 |
| arno11 | for example, if we grep most important things from irc logs + things from the user guide, then the AI could easely become a 'Leste virtual customer tech support agent' from conversations (just an idea) | 23:45 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
