| freemangordon | uvos: "fixing" osso-addressbook to recognize event_type is a hack and not going to work. Event types are el plugin specific and not part of any API. | 07:36 |
|---|---|---|
| freemangordon | also, I don;t see how we can distinguish between phone and SIP call | 07:45 |
| uvos__ | freemangordon: there is RTCOM_EL_PLUGIN_CALL_TYPE_VOIP and RTCOM_EL_PLUGIN_CALL_TYPE_GSM | 10:12 |
| uvos__ | yes you have to use the plugin to figure out what the type field is supposed to mean | 10:12 |
| uvos__ | you also have to use the plugin to know what any of the fields in the database mean, the plugins do do this differently | 10:13 |
| uvos__ | using the database directly like abook dose it broken, as can clearly be seen by the fact that it effectively hardcodes voip and gsm calls to not have a url in the remote_idenitifer field but then hardcodes all other types to be a uri | 10:15 |
| uvos__ | now you could argue this whole "plugin determines the meaning of fields" thing is stupid, and you would be right | 10:15 |
| uvos__ | its also really only half implemented | 10:15 |
| uvos__ | but thats how it nokia did it, fairly defficant. | 10:16 |
| uvos__ | we could change this by forgetting about the plugins and fixing the meaning of the database fields to allways be the same | 10:16 |
| uvos__ | but the choise to break compatability with fremantle databases should be made consciously | 10:17 |
| freemangordon | uvos__: oh, seems we already have something here https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/src/call-plugin.c#L266 | 12:43 |
| freemangordon | so we can just add vcard-field header when adding the event and I'll teach osso-abook to use it | 12:52 |
| freemangordon | sounds sane? | 12:52 |
| uvos__ | not sure i grok what you want to add exactly | 13:02 |
| uvos__ | a table of type -> field? | 13:02 |
| freemangordon | uvos__: I want to call rtcom_el_add_header("vcard-field", "tel") in sphone rtcomel plugin | 13:18 |
| freemangordon | here https://github.com/maemo-leste/sphone/blob/master/src/modules/store-rtcom.c#L83 | 13:18 |
| freemangordon | "Headers" table is already used as id->value table | 13:20 |
| freemangordon | https://github.com/maemo-leste/rtcom-eventlogger/blob/master/rtcom-eventlogger/eventlogger.h#L214 | 13:23 |
| uvos__ | freemangordon: ok thas fine for now | 13:27 |
| uvos__ | freemangordon: eventually the sphone backends sheme (https://github.com/maemo-leste/sphone/blob/e4f6af0d4d744f189ea0382846a6c1d9789c112e/src/modapi/comm.h#L34) should porbubaly be used instead of "tel" | 13:27 |
| uvos__ | also what about remote_uid when its not tel or sms | 13:28 |
| uvos__ | shal sphone append the sheme from the backend like fremantle | 13:28 |
| freemangordon | what else it could be? | 13:28 |
| uvos__ | or shal we fix remote_uid to never contain the theme? | 13:28 |
| uvos__ | *sheme | 13:28 |
| uvos__ | well tel:// and sms:// are still a wierd case where fremantle dosent prepend tel:// to remote_uid | 13:29 |
| uvos__ | while it dose prepend skype:// for instance | 13:29 |
| freemangordon | it does not prepend scheme to anything I have here | 13:29 |
| freemangordon | i took my el db from fremantle | 13:29 |
| freemangordon | no skype calls there though | 13:30 |
| uvos__ | hmm so why dose abook think the sheme should be in remote_uid? | 13:30 |
| freemangordon | maybe some remnant frm the old times | 13:30 |
| uvos__ | abooks code tries to determine the vcard field by handling remote_uid as a uri | 13:30 |
| freemangordon | no idea | 13:30 |
| freemangordon | yes | 13:30 |
| uvos__ | ok | 13:31 |
| freemangordon | but maybe some old version was working that way | 13:31 |
| uvos__ | so sphone shal never prepend, even when i add support for the backend sheme handling | 13:31 |
| uvos__ | ok | 13:31 |
| freemangordon | anyway, if you check call plugin code, there is a special support for vcard-field event value | 13:31 |
| uvos__ | sounds sane | 13:31 |
| freemangordon | mhm | 13:31 |
| freemangordon | ok, will make a PR when I have it working | 13:32 |
| uvos__ | ok | 13:32 |
| uvos__ | great | 13:32 |
| freemangordon | did you try latest changes? | 13:32 |
| freemangordon | libhildonmime etc | 13:32 |
| uvos__ | no not yet sorry, im out of town | 13:32 |
| freemangordon | ok | 13:32 |
| freemangordon | ok, back to RL work, ttyl | 13:32 |
| uvos__ | ttyl | 13:32 |
| Wizzup | the librem made it safely to my place | 18:42 |
| freemangordon | uvos: so, there is no way now to get the currently used scheme (in sphone that is)? | 18:45 |
| maxwelld | uvos, thank you for explanations. i am glad leste itself doesn't use much memory now. because i myself try to not use things that use lots of memory. | 18:52 |
| maxwelld | even on pinebook, when i run gentoo, if i see this is hard/slow to compile, i just don't use it anywhere, on a powerful laptop too. | 18:52 |
| maxwelld | i am a windowmaker/x11/xterm user with pidgin on laptops, well browser is a problem but i am trying to use netsurf and only rarely, if very necessary visit websites that are heavy and slow and have lots of js and ads etc. | 18:52 |
| Wizzup | freemangordon: with my sphone plugin each tp account is it's own sphone backend | 19:03 |
| freemangordon | ok, but can I get backend uri scheme somehow? | 19:05 |
| Wizzup | I will answer that tomorrow, I have a 7am meeting and it's 1:07am :) | 19:07 |
| freemangordon | ok | 19:07 |
| freemangordon | :) | 19:07 |
| Wizzup | backend_id = id; | 19:08 |
| Wizzup | backend_name = strdup(backend_id.toStdString().c_str()); | 19:08 |
| Wizzup | sphone_backend_id = sphone_comm_add_backend(backend_name, schemes,BACKEND_FLAG_CALL); | 19:08 |
| Wizzup | I think that might just be the full backend id as in telepathy qt | 19:08 |
| freemangordon | no, I need uri scheme like "tel", "sms", etc | 19:09 |
| Wizzup | you can get it using that I guess, not sure about scheme, I think it might register it, will need to check tomorrow | 19:13 |
| Wizzup | call_properties->needs_route = backend->type == "tel" | 19:13 |
| Wizzup | oh, nevermind, that is the tp backend and not sphone backend I think | 19:13 |
| Wizzup | oh, also for sphone you register it with a scheme | 19:14 |
| Wizzup | so probably there is a way to get it | 19:14 |
| Wizzup | static const Scheme call_scheme = { .scheme = (char*)"tel", .flags = BACKEND_FLAG_CALL | 19:14 |
| Wizzup | }; | 19:14 |
| freemangordon | it is a list of schemes unfortunately | 19:14 |
| freemangordon | we need uvos here I guess | 19:15 |
| Wizzup | he'll be back soon enough :) | 19:15 |
| * Wizzup zzz | 19:15 | |
| uvos | freemangordon: this bit isent finished yet, sphone's backends register shemes, but they are not used, except to find a backend to use when sphone is called by the xdg-open dispatcher | 20:27 |
| uvos | there currently is no api for sphones modules to read a backends shemes. | 20:27 |
| freemangordon | ok | 20:27 |
| uvos | that the schemes are a list | 20:28 |
| freemangordon | though so and hardcoded "tel" | 20:28 |
| uvos | yes | 20:28 |
| uvos | for now untill i finish this bit | 20:28 |
| freemangordon | mhm | 20:28 |
| freemangordon | https://github.com/maemo-leste/sphone/pull/6 | 20:29 |
| uvos | the fact that it is a list is just a hedge against the possibility that there could be several schemes that mean the same thing | 20:29 |
| uvos | eatch backend is expected to be one protocoll | 20:29 |
| uvos | so once this is finished using the first scheme in the list for the given backend should be safe | 20:29 |
| freemangordon | uvos: BTW, I would have used hash table in sphone_comm_get_backend() | 20:30 |
| uvos | assuming the flags match | 20:30 |
| uvos | freemangordon: sure yeah | 20:30 |
| uvos | would be better | 20:30 |
| freemangordon | uvos: when the (scheme) API is there, we will just unhardcode it | 20:30 |
| uvos | yup | 20:31 |
| freemangordon | could you have a glance ove the PR so I can push osso-addressbook changes? | 20:31 |
| uvos | freemangordon: "sphone_module_log(LL_ERR, "failed to add event to rtcom: %s");" <-- hmm | 20:33 |
| freemangordon | uh | 20:33 |
| freemangordon | sorry about that | 20:33 |
| uvos | np | 20:33 |
| freemangordon | will fix in a moment | 20:33 |
| freemangordon | though I wonder why compiler said nothing | 20:34 |
| uvos | maybe missing decorator | 20:35 |
| uvos | https://github.com/maemo-leste/sphone/blob/e4f6af0d4d744f189ea0382846a6c1d9789c112e/src/modapi/sphone-log.h#L42 | 20:36 |
| uvos | hmm maybe the fact tht its through a macro trips it up? | 20:36 |
| uvos | not sure | 20:36 |
| freemangordon | me neither | 20:36 |
| uvos | your hardcodeing tel also for messages | 20:40 |
| uvos | which is wrong, should be sms:// | 20:41 |
| freemangordon | no | 20:41 |
| freemangordon | this is not uri scheme ;) | 20:41 |
| uvos | sms dosent translate to the same vcard sheme? | 20:42 |
| freemangordon | but vcard-field | 20:42 |
| uvos | *field | 20:42 |
| freemangordon | vcard-field is not scheme | 20:42 |
| freemangordon | and sms, phone, tel, callto schemes, all translate to EVC_TEL | 20:42 |
| uvos | ok but my understanding was we where translateing schemes to vcard fields here | 20:43 |
| uvos | (which is something we need to do) | 20:43 |
| uvos | somewhere | 20:43 |
| uvos | if sphone needs to do this thats fine, but obv i need to be aware :P | 20:43 |
| freemangordon | so? we support sms:// and tel:// schemes. right? both are mapped to EVC_TEL vcard-field | 20:44 |
| uvos | sure, but atm sphone knows what sheme a backend supports | 20:44 |
| uvos | but not what vcard fields that is | 20:44 |
| freemangordon | and that's fine | 20:44 |
| freemangordon | but we have no API to know which scheme was used for the particular event | 20:45 |
| uvos | right, its just that later when we do have sutch api, we also need something to translate the scheme to vcard fields | 20:45 |
| freemangordon | right | 20:45 |
| freemangordon | the same like what _get_vcard_field_from_uri() in osso-addressbook does | 20:46 |
| uvos | right, just more robust, to put it mildly :P | 20:47 |
| freemangordon | mhm | 20:47 |
| freemangordon | or more complete I would say | 20:47 |
| freemangordon | maybe each backend shall provide mapping function | 20:47 |
| freemangordon | dunno how much you want eds compatibility | 20:48 |
| uvos | not sure yet | 20:48 |
| uvos | later | 20:48 |
| freemangordon | uvos: PRT updated | 20:48 |
| freemangordon | *PR | 20:49 |
| uvos | looks good | 20:50 |
| freemangordon | ok, please make a release when you have time, I will make a new release for abook | 20:55 |
| uvos | certenly | 20:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!