Ubuntu UDS-Boston, Syncing solutions
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
 |
|
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by John Carr-3
::
Rate this Message:
On Thu, 2007-11-01 at 07:12 -0400, Martin Owens wrote: > > Well there is lot of information which would be interesting to know. > > Starting on what fields and how much of them does phone support ending > > with available options to connect to it. First would be quite useful > > for all applications, while the latter for low level configuration of > > device (if we can not configure it automatically, user just selects > > phone from list and he will get list of possibilities how to connect to > > it). I thought many times about starting such database, but I never got > > to make it real. > > Hardware databases are being developed by other projects, including > but not limited to dohickey, ubuntu-hardware-tests and it looks like > these will be merged with more info being fed back into HAL as > required. > > So a quick overview: > > Conduit GUI for configuration http://mail.gnome.org/archives/conduit-list/2007-October/msg00033.html > New python gui for sync applet icon using dbus to conduit services > OpenSync wedged somehow into HAL for all hardware endpoints I was thinking along the lines of info.syncprovider = "opensync:pluginname" would be a nice simple starting point. And conduit: for our N800 and iPod stuff. > All information about phones to be put into HAL after callouts from > HAL this includes unique ID's and the sync engine required to operate > Conduit and opensync both changed to take advantage or awareness of > HAL if compiled to require it. Not sure how HAL fits into opensyncs plans, I think they see that as something to be sorted out higher up the stack - in the ui, conduit or some other intermediary daemon. > Callouts should return the user which the phone has been claimed to > belong and allow later on to extend this to any security on mobile > devices for syncing. (or none if it's brand new phone) > The default pim end points for ubuntu is evolution (begrudgingly) and > kubuntu is kde-pim for one click sync enable. > Let me know if I've missed any high level thoughts. > > Best Regards, Martin Owens > _______________________________________________ > Conduit-list mailing list > Conduit-list@... > http://mail.gnome.org/mailman/listinfo/conduit-list John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Daniel Gollub
::
Rate this Message:
On Thursday 01 November 2007 12:12:22 Martin Owens wrote:
> > Well there is lot of information which would be interesting to know. > > Starting on what fields and how much of them does phone support ending > > with available options to connect to it. First would be quite useful > > for all applications, while the latter for low level configuration of > > device (if we can not configure it automatically, user just selects > > phone from list and he will get list of possibilities how to connect to > > it). I thought many times about starting such database, but I never got > > to make it real. > > Hardware databases are being developed by other projects, including > but not limited to dohickey, ubuntu-hardware-tests and it looks like > these will be merged with more info being fed back into HAL as > required. As i already mentioned, I'm not a friend of hardware databases - especially if it's possible to detect the interface/service/protocoll in a certain way. Not quite sure if you know how complex the capabilities (fieldtype, number of fields, ...) of certain devices is... I only know a few protocols which are intended as synchronization and don't provide capabilities information. The few protocols which aren't intended to be a synchronization protocol but used to do syncing, mostly have fix set of capabilities. Best example for that is gnokii. You should ask Pawel Kot about that ;) Oh, i wonder in which format do you represent those fields, there are formats beside vCard 2.1 and vCalendar. Would be very intersting, we're facing the same problem in OpenSync. I agree in one point: It would be very nice which synchronization protocol are supported by the connected device. > > So a quick overview: > > Conduit GUI for configuration > New python gui for sync applet icon using dbus to conduit services > OpenSync wedged somehow into HAL for all hardware endpoints Where get the conflict handling callbacks implemented? > All information about phones to be put into HAL after callouts from > HAL this includes unique ID's and the sync engine required to operate This actually should be only the synchronization protocoll... more isn't needed. At least the frontends of OpenSync doesn't need more then: "syncml-via-obex", "irmc", "palm-hotsync", ... So they can choose the right plugin, trigger the discovery process of the plugin and get all the capabilities information ... in a protocoll specific way. Unique ID sounds intersting ... should this be done by a callout process? What do you want to use as Unique ID? IMEI? > Conduit and opensync both changed to take advantage or awareness of > HAL if compiled to require it. To clarify that: We don't touch OpenSync for that - we touch the OpenSync frontends, but not OpenSync itself. OpenSync have to stay simple and platform independent. It's the task of the OpenSync frontend (KitchenSync, MultiSync 0.9x, gnome-sync-tool, Conduit, ....) to listen to HAL, .... > Callouts should return the user which the phone has been claimed to > belong and allow later on to extend this to any security on mobile > devices for syncing. (or none if it's brand new phone) This sounds interesting, but i wonder how to do that... Is there already an example implementation for other devices? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Daniel Gollub
::
Rate this Message:
On Thursday 01 November 2007 02:29:10 John Stowers wrote:
> On 11/1/07, John Carr <john.carr@...> wrote: > > I think for now its more sane (and least effort) for us just to use the > > opensync plugin... If I can get my P900 all set up then theres no reason > > why this wouldnt be viable. And write a HAL callout in C or Vala to poke > > and probe for capabilities. > > I think as a first pass, and as john mentioned, we are very close to > hosting opensync plugins in conduit. I really have certain doubts that you're just hijacking the OpenSync plugins and write your own synchronization logic. So the whole complexity of the OpenSync engine would be just duplicated ... Actually this was the basic idea of OpenSync to avoid such thing again. To reimplement just another synchronization-something-application which has a half implemented synchronization logic. So conflict handing, mappings, slow-syncing, comparing of changes, format conversation, objtype handling and so on get implemented once again.. Maybe, i missed something... could you clarify that? Sure, Conduit has some fancy stuff like syncing something else then PIM data... but OpenSync is currently specialized in syncing content-specific data which could be in different formats, like PIM. But this might be change in future... best regards, Daniel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by DoctorMO
::
Rate this Message:
> I really have certain doubts that you're just hijacking the OpenSync plugins
> and write your own synchronization logic. So the whole complexity of the > OpenSync engine would be just duplicated ... Right, but that is because a) both teams have created syn logic b) neither team has made their sync logic a separate module that can be used on it's own c) conduit believes it needs only hardware support d) opensync believes it only needs a gui on top of the existing platform. The truth is that opensync attempts at gui's have been awful, it's not integrated into dbus for sync control; it doesn't use HAL for hardware management or detecting when hardware is plugged in; it's terrible at passing information about hardware around and has a rather non-automatic configuration path that makes it hellish to set up end points and doesn't have support for filters and media translations (yet) Where as conduit has almost no hardware syncing support, also doesn't use HAL for managing hardware (yet), has poorer conflict resolution and syncing logic and used to have a problem with having gdk (gnome) requirements. I do not believe either team can produce anything complete and useful by it's self and the reason for the dialog and meeting is so we can talk about how to merge, promote or decommission various parts of each project so we acquire all strengths in the end functionality. The conduit guys want to take all the hardware support, by use of an extension of some kind. I've not heard any solutions from opensync yet. Best Regards, Martin Owens ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by DoctorMO
::
Rate this Message:
Times for you all, rather short notice, sorry:
http://people.ubuntu.com/~scott/uds-boston-2007/2007-11-01/ On 01/11/2007, Martin Owens <doctormo@...> wrote: > > I really have certain doubts that you're just hijacking the OpenSync plugins > > and write your own synchronization logic. So the whole complexity of the > > OpenSync engine would be just duplicated ... > > Right, but that is because a) both teams have created syn logic b) > neither team has made their sync logic a separate module that can be > used on it's own c) conduit believes it needs only hardware support d) > opensync believes it only needs a gui on top of the existing platform. > > The truth is that opensync attempts at gui's have been awful, it's not > integrated into dbus for sync control; it doesn't use HAL for hardware > management or detecting when hardware is plugged in; it's terrible at > passing information about hardware around and has a rather > non-automatic configuration path that makes it hellish to set up end > points and doesn't have support for filters and media translations > (yet) > > Where as conduit has almost no hardware syncing support, also doesn't > use HAL for managing hardware (yet), has poorer conflict resolution > and syncing logic and used to have a problem with having gdk (gnome) > requirements. > > I do not believe either team can produce anything complete and useful > by it's self and the reason for the dialog and meeting is so we can > talk about how to merge, promote or decommission various parts of each > project so we acquire all strengths in the end functionality. > > The conduit guys want to take all the hardware support, by use of an > extension of some kind. > I've not heard any solutions from opensync yet. > > Best Regards, Martin Owens > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Daniel Gollub
::
Rate this Message:
On Thursday 01 November 2007 14:41:33 Martin Owens wrote:
> > I really have certain doubts that you're just hijacking the OpenSync > > plugins and write your own synchronization logic. So the whole complexity > > of the OpenSync engine would be just duplicated ... > > Right, but that is because a) both teams have created syn logic b) > neither team has made their sync logic a separate module that can be > used on it's own c) conduit believes it needs only hardware support d) > opensync believes it only needs a gui on top of the existing platform. a) Thats OpenSource .. you need to hit the right balance to reinvent the wheel. b) Separate module? What's OpenSync? c) Agree. d) Agree. > > The truth is that opensync attempts at gui's have been awful, it's not > integrated into dbus for sync control; it doesn't use HAL for hardware > management or detecting when hardware is plugged in; it's terrible at > passing information about hardware around and has a rather > non-automatic configuration path that makes it hellish to set up end > points and doesn't have support for filters and media translations > (yet) Correct - yet. On HackWeek i had the idea about "MobileStation", i guess you're not aware of that... MobileStation is intended to be a D-Bus Session daemon which should provide a D-Bus API. OpenSync is just a framework for synchronization and should only provide the facility to do simple synchronization. And not provide directly a D-Bus interface... Anyway here was a PoC of MobileStation: http://www.opensync.org/browser/branches/MobileStation/MobileStation-api.txt In meanwhile i had certain other ideas how to redesign this. For example to allow other OpenSync frontends like KitchenSync, gnome-sync-tool, MultiSync, Conduit, .. to register as Synchronization Agents. Not quite sure if you're familiar with this kind of Agent Implementation. I got inspired by Marcel's BlueZ D-Bus interface .. which works quite well. http://cryptomilch.de/~dgollub/OpenSync/mobilestation.png Actually most of the sync parties should involved in this MobileStation PoC. Unfortunately it doesn't look like you heard of that... > > Where as conduit has almost no hardware syncing support, also doesn't > use HAL for managing hardware (yet), has poorer conflict resolution > and syncing logic and used to have a problem with having gdk (gnome) > requirements. OpenSync goals is also to be desktop independent... > > I do not believe either team can produce anything complete and useful > by it's self and the reason for the dialog and meeting is so we can > talk about how to merge, promote or decommission various parts of each > project so we acquire all strengths in the end functionality. ... > > The conduit guys want to take all the hardware support, by use of an > extension of some kind. > I've not heard any solutions from opensync yet. Since hardware detection isn't platform independent it shouldn't be done by OpenSync itself. To keep it platformat independent and "keep it simple, stupid". And i see only advantage if this kind of hardware implementation will be done out of OpenSync. For example KitchenSync for KDE4 would fully rely on Solid, so it could design Bluetooth Discovery Widgets which are platform independent. So if someone wants to use KitchenSync on Windows there is no code change need to search for Bluetooth devices. Same should be for devices connected via USB. Not quite sure about GNOME if there is any platform which doesn't run HAL anyway. But i see no reason why gnome-sync-tool or MultiSync shouldn't just listen on D-Bus for HAL signals and start some wizard or syncing if some synchronizable device got connected. Same for the current BlueZ D-Bus API - you don't have to write a lot code to implement that ... And there might be application which use OpenSync which don't need any hardware detection - e.g. embedded devices. For example if i want to sync my N800 and my mobile without any PC - then i don't want to listen on HAL since i can't connect my mobile via USB to the N800. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by John Carr-3
::
Rate this Message:
So many e-mails to reply to!
On Thu, 2007-11-01 at 14:31 +0100, Daniel Gollub wrote: > On Thursday 01 November 2007 02:29:10 John Stowers wrote: > > On 11/1/07, John Carr <john.carr@...> wrote: > > > I think for now its more sane (and least effort) for us just to use the > > > opensync plugin... If I can get my P900 all set up then theres no reason > > > why this wouldnt be viable. And write a HAL callout in C or Vala to poke > > > and probe for capabilities. > > > > I think as a first pass, and as john mentioned, we are very close to > > hosting opensync plugins in conduit. > > I really have certain doubts that you're just hijacking the OpenSync plugins > and write your own synchronization logic. So the whole complexity of the > OpenSync engine would be just duplicated ... As i've stated repeatedly. This is phase 1. I openly admit that opensync is better at PIM syncing. That is why I started looking at opensync integration. I'm one of the SynCE devs so I have enough experience to directly hook up Conduit and SynCE without putting opensync in the middle. So please don't accuse me of anything dodgey! Conduit hasn't made its opensync policy clear enough, *I personally* want good integration between our two projects. Otherwise I would have SynceModule and not OpenSyncModule sat in our trunk right now. > Actually this was the basic idea of OpenSync to avoid such thing again. > To reimplement just another synchronization-something-application which has a > half implemented synchronization logic. So conflict handing, mappings, > slow-syncing, comparing of changes, format conversation, objtype handling and > so on get implemented once again.. Conduit started out to make sync "just work". We want to build a high level of integration with the desktop. The sync we built in was just a means to and end, as the python bindings for opensync at the time werent really there (and we /did/ send patches...). OpenSyncModule has proven itself so that situation must have changed and hence why i'm trying to move forward on unification. > Sure, Conduit has some fancy stuff like syncing something else then PIM > data... but OpenSync is currently specialized in syncing content-specific > data which could be in different formats, like PIM. But this might be change > in future... We've done a lot of integration work which we can't just abandon. OpenSyncModule gets us there without breaking thinks like Files, Tomboy notes, and gconf keys that get automatically sync'd. So when I create a tomboy note it will just be synced wherever. It means we can keep our HAL integration for iPods and N800 and extend it to cover PDAs and phones. We can't afford to lose this integration because if we do, we lose. Right now there are a lot of projects that want sync. If we can't provide a unified sync solution thats well integrated into the desktop then the GNOME Online Desktop stuff will. And it won't learn from conduit or opensync. It will reimplement sync on its own. And its already begun. John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Michal Čihař
::
Rate this Message:
Hi
Dne Thu, 1 Nov 2007 14:10:06 +0100 Daniel Gollub <dgollub@...> napsal(a): > As i already mentioned, I'm not a friend of hardware databases - especially if > it's possible to detect the interface/service/protocoll in a certain way. Not > quite sure if you know how complex the capabilities (fieldtype, number of > fields, ...) of certain devices is... About the fields there is sometimes only reliable way to try to write it. Eg. over IrMC, phones can somehow export what they support, but you can not tell from that how many phone numbers you can store on them. The other thing which you usually can not find out until actually trying to write and item is maximal length of fields. I also do not like idea of hardware database, but I also do not think that trying to write to every device just to find out capabilities is a good solution. > I only know a few protocols which are intended as synchronization and don't > provide capabilities information. The few protocols which aren't intended to > be a synchronization protocol but used to do syncing, mostly have fix set of > capabilities. Best example for that is gnokii. You should ask Pawel Kot about > that ;) Well I do Gammu (fork of Gnokii long time ago), so I pretty good know the situation here. You have fixed set of capabilities per protocol, but each phone actually supports some subset of this. Look at Nokia phones, they always add new fields to new models so you add them to protocol, but the old phones will reject them. > This actually should be only the synchronization protocoll... more isn't > needed. At least the frontends of OpenSync doesn't need more > then: "syncml-via-obex", "irmc", "palm-hotsync", ... > So they can choose the right plugin, trigger the discovery process of the > plugin and get all the capabilities information ... in a protocoll specific > way. > > Unique ID sounds intersting ... should this be done by a callout process? > What do you want to use as Unique ID? IMEI? For bluetooth you can use MAC address, not sure about others. BTW: I cut down CC list a bit, hopefully I didn't remove anybody who is not on the lists. No need to CC me on reply, I'm subscribed to opensync-devel. -- Michal Čihař | http://cihar.com | http://blog.cihar.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Daniel Gollub
::
Rate this Message:
On Thursday 01 November 2007 16:37:44 Michal Čihař wrote:
> Dne Thu, 1 Nov 2007 14:10:06 +0100 > > Daniel Gollub <dgollub@...> napsal(a): > > As i already mentioned, I'm not a friend of hardware databases - > > especially if it's possible to detect the interface/service/protocoll in > > a certain way. Not quite sure if you know how complex the capabilities > > (fieldtype, number of fields, ...) of certain devices is... > > About the fields there is sometimes only reliable way to try to write > it. Eg. over IrMC, phones can somehow export what they support, > but you can not tell from that how many phone numbers you can store on > them. The other thing which you usually can not find out until actually > trying to write and item is maximal length of fields. > > I also do not like idea of hardware database, but I also do not think > that trying to write to every device just to find out capabilities is a > good solution. > > > I only know a few protocols which are intended as synchronization and > > don't provide capabilities information. The few protocols which aren't > > intended to be a synchronization protocol but used to do syncing, mostly > > have fix set of capabilities. Best example for that is gnokii. You should > > ask Pawel Kot about that ;) > > Well I do Gammu (fork of Gnokii long time ago), so I pretty good know > the situation here. You have fixed set of capabilities per protocol, but > each phone actually supports some subset of this. Look at Nokia phones, > they always add new fields to new models so you add them to protocol, > but the old phones will reject them. What about older (Nokia) mobiles which didn't support IrMC and SyncML? Do they have a fix set of capabilities? I'm speaking now just about syncing (not the phone manager tools which using gammu and gnokii), but i would recommend to just use by default the minimum set of known capabilities for the older phones. Since if the mobile supports SyncML it should be used to do syncing. The next would be IrMC and then gnokii/gammu... but this wouldn't bring any benefit for gnokii or gammu. I'm aware of the Phone-utopia project. Maybe there you should build some common base for capabilities for older (and maybe newer) mobiles. Maybe the OMA vObject Minimum Interoperability Profile fits even the capabilities set of older mobiles and would be a good base to start with: http://www.openmobilealliance.org/release_program/vObject_v1_0.html At least i plan to fit the needs of vObject with the OpenSync vformat plugin... What about unifying efforts in phone-utopia to collect such basic capabilities. It would also interesting to get there a basic set of AT+ commands... I would suggest to make this set of capabilities independent of HAL, since it's just fixed data. This would allow other application and OpenSync to fallback to get information like which fields are support and (what isn't often provided even not always by SyncML) what is the max occur of this field. OpenSync 0.3x has an own implementation to provide fixed capabilities. But we intend to make only use of fixed capabilities if it's really needed. For example if the firmware of the mobile is buggy, and can't store the ZIP code of the 3rd Address (like my Palm T|X) - so we overwrite the reported capability set of the device with a fixed set of capabilities which workaround this bug. But this is only in rare cases. Currently for gnokii-sync we would need to write a minimum set of capabilities which are supported by all mobiles. And write further capabilities for mobiles which are known to support more fields... but if gnokii/gammu or even phone-utopia could provide this own data would be only a fallback solution. > > > This actually should be only the synchronization protocoll... more isn't > > needed. At least the frontends of OpenSync doesn't need more > > then: "syncml-via-obex", "irmc", "palm-hotsync", ... > > So they can choose the right plugin, trigger the discovery process of the > > plugin and get all the capabilities information ... in a protocoll > > specific way. > > > > Unique ID sounds intersting ... should this be done by a callout process? > > What do you want to use as Unique ID? IMEI? > > For bluetooth you can use MAC address, not sure about others. missing. Regarding the meeting minutes of the last BlueZ developer meeting HAL integration will be done with BlueZ 5.0 http://wiki.bluez.org/wiki/Meeting-2007-09-12 So for now i recommend to listen to HAL and BlueZ D-Bus signals ... I see more the problem about a unique ID for devices connected via USB. Two mobiles, connected via USB, same models, two different users, same system - usecase: laptop pool. (It's not about multiseat, but could be as well, it's more about different sessions for now ...) Often the vendor software probes for the IMEI with AT+ commands. (Not quite sure how the IMEI should be handled, since it's kind of sensitive, isn't it?) AFAIK, without triggering a sync this is the only way to identify the mobile. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Pawel Kot
::
Rate this Message:
Hi,
On 11/1/07, Daniel Gollub <dgollub@...> wrote: > On Thursday 01 November 2007 16:37:44 Michal Čihař wrote: > > Dne Thu, 1 Nov 2007 14:10:06 +0100 > > Daniel Gollub <dgollub@...> napsal(a): > > > I only know a few protocols which are intended as synchronization and > > > don't provide capabilities information. The few protocols which aren't > > > intended to be a synchronization protocol but used to do syncing, mostly > > > have fix set of capabilities. Best example for that is gnokii. You should > > > ask Pawel Kot about that ;) > > > > Well I do Gammu (fork of Gnokii long time ago), so I pretty good know > > the situation here. You have fixed set of capabilities per protocol, but > > each phone actually supports some subset of this. Look at Nokia phones, > > they always add new fields to new models so you add them to protocol, > > but the old phones will reject them. > > What about older (Nokia) mobiles which didn't support IrMC and SyncML? > Do they have a fix set of capabilities? Well, not really. There are some phone series that do have the same capabilities. Few years ago there were just few phones available. These days we have hundreds of phones and they differ a lot between themselves. > I'm speaking now just about syncing (not the phone manager tools which using > gammu and gnokii), but i would recommend to just use by default the minimum > set of known capabilities for the older phones. Since if the mobile supports > SyncML it should be used to do syncing. The next would be IrMC and then > gnokii/gammu... but this wouldn't bring any benefit for gnokii or gammu. I'm > aware of the Phone-utopia project. Maybe there you should build some common > base for capabilities for older (and maybe newer) mobiles. My understanding of HAL is that despite of plug/unplug information it has also some kind of the hardware database. IMHO creating another database is not the right way to go. I know that not many applications will use it. But certainly "our" database will need to duplicate HAL information. By the way, in the Windows-Nokia world it has the worst solution I could imagine. The capabilities are hardcoded into the application. Sequent capabilities are added in the sequent PC Suite releases. And if you have older phone you cannot use new PC Suite version (there's a wizzard on their website telling you which app version you need to download). > Maybe the OMA vObject Minimum Interoperability Profile fits even the > capabilities set of older mobiles and would be a good base to start with: > > http://www.openmobilealliance.org/release_program/vObject_v1_0.html I am afraid that is not enough. The problem is that if you want to store some vcard and a phone doesn't support some field you want to store, it won't tell you that. It will reject the frame (when talking about FBUS protocol). Fortunately you can group phones into certain cababilities model. I already have designed some simple relation group model, but I belive that having separate database for the phone managers is the wrong architectural decision. > At least i plan to fit the needs of vObject with the OpenSync vformat > plugin... > > What about unifying efforts in phone-utopia to collect such basic > capabilities. It would also interesting to get there a basic set of AT+ > commands... > > I would suggest to make this set of capabilities independent of HAL, since > it's just fixed data. This would allow other application and OpenSync to > fallback to get information like which fields are support and (what isn't > often provided even not always by SyncML) what is the max occur of this > field. I will provide a model I have on phone-utopia wiki (I think I'll move my gnokii devel branch work into p-u) but still, I am convinced that it will duplicate partailly something already exists. > OpenSync 0.3x has an own implementation to provide fixed capabilities. But we > intend to make only use of fixed capabilities if it's really needed. For > example if the firmware of the mobile is buggy, and can't store the ZIP code > of the 3rd Address (like my Palm T|X) - so we overwrite the reported > capability set of the device with a fixed set of capabilities which > workaround this bug. But this is only in rare cases. But first you need to know, if the device supports ZIP code at all, right? > Currently for gnokii-sync we would need to write a minimum set of capabilities > which are supported by all mobiles. And write further capabilities for > mobiles which are known to support more fields... but if gnokii/gammu or even > phone-utopia could provide this own data would be only a fallback solution. I don't think I follow this logic. Could you explain in more detail? > > > This actually should be only the synchronization protocoll... more isn't > > > needed. At least the frontends of OpenSync doesn't need more > > > then: "syncml-via-obex", "irmc", "palm-hotsync", ... > > > So they can choose the right plugin, trigger the discovery process of the > > > plugin and get all the capabilities information ... in a protocoll > > > specific way. > > > > > > Unique ID sounds intersting ... should this be done by a callout process? > > > What do you want to use as Unique ID? IMEI? > > > > For bluetooth you can use MAC address, not sure about others. > Yes, bluetooth is easy .. but currently the BlueZ integration in HAL is > missing. Regarding the meeting minutes of the last BlueZ developer meeting > HAL integration will be done with BlueZ 5.0 > > http://wiki.bluez.org/wiki/Meeting-2007-09-12 > > So for now i recommend to listen to HAL and BlueZ D-Bus signals ... > I see more the problem about a unique ID for devices connected via USB. Two > mobiles, connected via USB, same models, two different users, same system - > usecase: laptop pool. (It's not about multiseat, but could be as well, it's > more about different sessions for now ...) IrDA is problem as well, > Often the vendor software probes for the IMEI with AT+ commands. > (Not quite sure how the IMEI should be handled, since it's kind of sensitive, > isn't it?) It is. Additionally it can be changed (although it is illegal in some countries). On the other hand Nokia PC Suite uses IMEI as a phone identifier. take care, pkot PS. I'm CCing Daniele, who may also be interested in this discussion part. -- Pawel Kot ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Daniel Gollub
::
Rate this Message:
On Thursday 01 November 2007 17:50:50 Pawel Kot wrote:
> > What about older (Nokia) mobiles which didn't support IrMC and SyncML? > > Do they have a fix set of capabilities? > > Well, not really. There are some phone series that do have the same > capabilities. Few years ago there were just few phones available. > These days we have hundreds of phones and they differ a lot between > themselves. Yeah, but those older phones which doesn't support SyncML nor IrMC should have nearly the same minimal set of capabilities - right? > > > I'm speaking now just about syncing (not the phone manager tools which > > using gammu and gnokii), but i would recommend to just use by default the > > minimum set of known capabilities for the older phones. Since if the > > mobile supports SyncML it should be used to do syncing. The next would be > > IrMC and then gnokii/gammu... but this wouldn't bring any benefit for > > gnokii or gammu. I'm aware of the Phone-utopia project. Maybe there you > > should build some common base for capabilities for older (and maybe > > newer) mobiles. > > My understanding of HAL is that despite of plug/unplug information it > has also some kind of the hardware database. IMHO creating another > database is not the right way to go. I know that not many applications > will use it. But certainly "our" database will need to duplicate HAL > information. Check /usr/share/hal/fdi/* Maybe a interesting example is /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi Which is a generated fdi file from libgphoto2. Example entries: <match key="usb.vendor_id" int="1276"> <match key="usb.product_id" int="20555"> <merge key="info.category" type="string">camera</merge> <append key="info.capabilities" type="strlist">camera</append> <merge key="camera.access_method" type="string">proprietary</merge> <merge key="camera.libgphoto2.name" type="string">Aiptek Smart Megacam</merge> <merge key="camera.libgphoto2.support" type="bool">true</merge> </match> </match> <match key="usb.vendor_id" int="1452"> <match key="usb.product_id" int="4752"> <merge key="info.category" type="string">camera</merge> <append key="info.capabilities" type="strlist">camera</append> <merge key="camera.access_method" type="string">ptp</merge> <merge key="camera.libgphoto2.name" type="string">Apple iPhone (PTP mode)</merge> <merge key="camera.libgphoto2.support" type="bool">true</merge> </match> > > By the way, in the Windows-Nokia world it has the worst solution I > could imagine. The capabilities are hardcoded into the application. > Sequent capabilities are added in the sequent PC Suite releases. And > if you have older phone you cannot use new PC Suite version (there's a > wizzard on their website telling you which app version you need to > download). Full agree, i often hit the problem even with Nokia mobiles and SyncML. We have to set/fake the identifier string for certain mobiles. On some mobiles it is "PC Suite" on other it's "PC Suite Data Sync" - otherwise the mobile reject with a "internal server error".... > > > Maybe the OMA vObject Minimum Interoperability Profile fits even the > > capabilities set of older mobiles and would be a good base to start with: > > > > http://www.openmobilealliance.org/release_program/vObject_v1_0.html > > I am afraid that is not enough. The problem is that if you want to > store some vcard and a phone doesn't support some field you want to > store, it won't tell you that. It will reject the frame (when talking > about FBUS protocol). Fortunately you can group phones into certain > cababilities model. I already have designed some simple relation group > model, but I belive that having separate database for the phone > managers is the wrong architectural decision. Did you really check vObject spec - is even this minimum set of capabilities to complex for older mobiles? > > > At least i plan to fit the needs of vObject with the OpenSync vformat > > plugin... > > > > What about unifying efforts in phone-utopia to collect such basic > > capabilities. It would also interesting to get there a basic set of AT+ > > commands... > > > > I would suggest to make this set of capabilities independent of HAL, > > since it's just fixed data. This would allow other application and > > OpenSync to fallback to get information like which fields are support and > > (what isn't often provided even not always by SyncML) what is the max > > occur of this field. > > I will provide a model I have on phone-utopia wiki (I think I'll move > my gnokii devel branch work into p-u) but still, I am convinced that > it will duplicate partailly something already exists. > > > OpenSync 0.3x has an own implementation to provide fixed capabilities. > > But we intend to make only use of fixed capabilities if it's really > > needed. For example if the firmware of the mobile is buggy, and can't > > store the ZIP code of the 3rd Address (like my Palm T|X) - so we > > overwrite the reported capability set of the device with a fixed set of > > capabilities which workaround this bug. But this is only in rare cases. > > But first you need to know, if the device supports ZIP code at all, right? Palms only differ in two different - afaik) or you can request them (SyncML, IrMC, ...) > > > Currently for gnokii-sync we would need to write a minimum set of > > capabilities which are supported by all mobiles. And write further > > capabilities for mobiles which are known to support more fields... but if > > gnokii/gammu or even phone-utopia could provide this own data would be > > only a fallback solution. > > I don't think I follow this logic. Could you explain in more detail? If you want to sync for example Mobile xyz and the mobile supports: SyncML, IrMC and F-BUS. Then it should prefer SyncML - since it can request the capabilities. If it would only support IrMC and FBUS, it should prefer IrMC, it also can report capabilities. If the mobile supports only FBUS it should try with a known minimum set of capabilities provided by gnokii/gammu/phone-utopia. Not quite sure if gnokii already provides such fixed capabilities information by protocol/model via the libgnokii API. But if not we could write for gnokii-sync own capabilities files for certain devices and package them with the plugin. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <versions version="0.1"> <version> <PlugIn>gnokii-sync</PlugIn> <Priority>100</Priority> <Vendor></Vendor> <ModelVersion>6310i</ModelVersion> <FirmwareVersion></FirmwareVersion> <SoftwareVersion></SoftwareVersion> <HardwareVersion></HardwareVersion> <Identifier>gnokii-6310i.xml</Identifier> </version> <version> <PlugIn>gnokii-sync</PlugIn> <Priority>100</Priority> <Vendor></Vendor> <ModelVersion></ModelVersion> <FirmwareVersion></FirmwareVersion> <SoftwareVersion></SoftwareVersion> <HardwareVersion></HardwareVersion> <Identifier>gnokii-minimumset.xml</Identifier> </version> </versions> gnokii-6310i.xml: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <capabilities> <contact> <AddressLabel /> <Categories /> <EMail /> <FormattedName /> <Telephone /> <Url /> </contact> </capabilities> gnokii-minimumset.xml: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <capabilities> <contact> <AddressLabel /> <Categories /> <FormattedName /> <Telephone /> </contact> </capabilities> If i know package those capabilties files into gnokii-sync and configure gnokii-sync with <model>6600</model> it will fallback to the capabilities explained in gnokii-minimumset.xml. If would set <model> to 6310i it would fist match gnokii-6310i.xml > > > > > This actually should be only the synchronization protocoll... more > > > > isn't needed. At least the frontends of OpenSync doesn't need more > > > > then: "syncml-via-obex", "irmc", "palm-hotsync", ... > > > > So they can choose the right plugin, trigger the discovery process of > > > > the plugin and get all the capabilities information ... in a > > > > protocoll specific way. > > > > > > > > Unique ID sounds intersting ... should this be done by a callout > > > > process? What do you want to use as Unique ID? IMEI? > > > > > > For bluetooth you can use MAC address, not sure about others. > > > > Yes, bluetooth is easy .. but currently the BlueZ integration in HAL is > > missing. Regarding the meeting minutes of the last BlueZ developer > > meeting HAL integration will be done with BlueZ 5.0 > > > > http://wiki.bluez.org/wiki/Meeting-2007-09-12 > > > > So for now i recommend to listen to HAL and BlueZ D-Bus signals ... > > I see more the problem about a unique ID for devices connected via USB. > > Two mobiles, connected via USB, same models, two different users, same > > system - usecase: laptop pool. (It's not about multiseat, but could be as > > well, it's more about different sessions for now ...) > > IrDA is problem as well, > > > Often the vendor software probes for the IMEI with AT+ commands. > > (Not quite sure how the IMEI should be handled, since it's kind of > > sensitive, isn't it?) > > It is. Additionally it can be changed (although it is illegal in some > countries). On the other hand Nokia PC Suite uses IMEI as a phone > identifier. But this case shouldn't be supported... ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Pawel Kot-5
::
Rate this Message:
Hi,
On 11/1/07, Daniel Gollub <dgollub@...> wrote: > On Thursday 01 November 2007 17:50:50 Pawel Kot wrote: > > > What about older (Nokia) mobiles which didn't support IrMC and SyncML? > > > Do they have a fix set of capabilities? > > > > Well, not really. There are some phone series that do have the same > > capabilities. Few years ago there were just few phones available. > > These days we have hundreds of phones and they differ a lot between > > themselves. > > Yeah, but those older phones which doesn't support SyncML nor IrMC should have > nearly the same minimal set of capabilities - right? Depends on what level of granularity you define capabilities. > > > I'm speaking now just about syncing (not the phone manager tools which > > > using gammu and gnokii), but i would recommend to just use by default the > > > minimum set of known capabilities for the older phones. Since if the > > > mobile supports SyncML it should be used to do syncing. The next would be > > > IrMC and then gnokii/gammu... but this wouldn't bring any benefit for > > > gnokii or gammu. I'm aware of the Phone-utopia project. Maybe there you > > > should build some common base for capabilities for older (and maybe > > > newer) mobiles. > > > > My understanding of HAL is that despite of plug/unplug information it > > has also some kind of the hardware database. IMHO creating another > > database is not the right way to go. I know that not many applications > > will use it. But certainly "our" database will need to duplicate HAL > > information. > > Check /usr/share/hal/fdi/* > > Maybe a interesting example is > /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi It fits exactly my needs. I'd like for every device having defined which group of features does it support. For example: <match key="usb.vendor_id" int="0x0421"> <match key="usb.product_id" int="0x0428"> <merge key="info.category" type="string">mobile_phone</merge> <append key="info.capabilities" type="strlist">mobile_phone</append> <merge key="mobile_phone.name" type="string">Nokia 6230i</merge> <merge key="mobile_phone.syncml" type="string">yes</merge> <merge key="mobile_phone.connection" type="strlist">bluetooth</merge> <append key="mobile_phone.connection" type="strlist">irda</append> <append key="mobile_phone.connection" type="strlist">usb_dku2</append> <merge key="mobile_phone.driver" type="strlist">AT</merge> <append key="mobile_phone.driver" type="strlist">series40</append> <merge key="mobile_phone.name" type="string">Nokia 6230i</merge> <!-- I am not sure at the moment if it would be required --> <merge key="mobile_phone.series40.phonebook" type="string">nokia_extended</merge> <!-- vcard21, vcard30, nokia_dct3, nokia_series40, nokia_series40_3rdEd, symbian, ... --> <merge key="mobile_phone.AT.phonebook" type="string">vcard30</merge> </match> </match> I think I could work more on this example, but this is kind of information I need, and HAL db seems to be a perfect match. Although it again duplicates somehow what is in udev rules. Udev rules describe the same devices as HAL configuration. And it is easier to add configuration in one place then in serveral places. > > By the way, in the Windows-Nokia world it has the worst solution I > > could imagine. The capabilities are hardcoded into the application. > > Sequent capabilities are added in the sequent PC Suite releases. And > > if you have older phone you cannot use new PC Suite version (there's a > > wizzard on their website telling you which app version you need to > > download). > > Full agree, i often hit the problem even with Nokia mobiles and SyncML. We > have to set/fake the identifier string for certain mobiles. On some mobiles > it is "PC Suite" on other it's "PC Suite Data Sync" - otherwise the mobile > reject with a "internal server error".... Yeah. And again, identifier could be a property for the device in HAL db. > > > Maybe the OMA vObject Minimum Interoperability Profile fits even the > > > capabilities set of older mobiles and would be a good base to start with: > > > > > > http://www.openmobilealliance.org/release_program/vObject_v1_0.html > > > > I am afraid that is not enough. The problem is that if you want to > > store some vcard and a phone doesn't support some field you want to > > store, it won't tell you that. It will reject the frame (when talking > > about FBUS protocol). Fortunately you can group phones into certain > > cababilities model. I already have designed some simple relation group > > model, but I belive that having separate database for the phone > > managers is the wrong architectural decision. > > Did you really check vObject spec - is even this minimum set of capabilities > to complex for older mobiles? I meant two things. This specification doesn't cover all my needs (ie. phonebook, calendar are not enough). Old mobiles are not compliant with VCARD21 (some of them). But still: you need to know with which vCard specification a phone is compliant. Where do you get this information from? > > > OpenSync 0.3x has an own implementation to provide fixed capabilities. > > > But we intend to make only use of fixed capabilities if it's really > > > needed. For example if the firmware of the mobile is buggy, and can't > > > store the ZIP code of the 3rd Address (like my Palm T|X) - so we > > > overwrite the reported capability set of the device with a fixed set of > > > capabilities which workaround this bug. But this is only in rare cases. > > > > But first you need to know, if the device supports ZIP code at all, right? > Correct... but beside FBUS most protocols really have fixed capabilities (like > Palms only differ in two different - afaik) or you can request them (SyncML, > IrMC, ...) Perhaps I don't know what I am taking about, but in this case it is not SyncML but vCard2.1 or vCard 3.0 which define real capabilities. So I may prepare for myself some other specifications, like NokiaPBook1.0, NokiaPBook2.0, .... And that's fine. I just would like to have someone to tell me: Hey, some device got just connected. It supports NokiaPBook 2.0 in FBUS mode and vCard 3.0 in obex mode. > > > Currently for gnokii-sync we would need to write a minimum set of > > > capabilities which are supported by all mobiles. And write further > > > capabilities for mobiles which are known to support more fields... but if > > > gnokii/gammu or even phone-utopia could provide this own data would be > > > only a fallback solution. > > > > I don't think I follow this logic. Could you explain in more detail? > If you want to sync for example Mobile xyz and the mobile supports: SyncML, > IrMC and F-BUS. Then it should prefer SyncML - since it can request the > capabilities. If it would only support IrMC and FBUS, it should prefer IrMC, If SyncML has an option to ask for capabilities that's great. Just remember that claiming being compatible with spec, doesn't mean being compatible. So I still think you will need some database for the exceptions. > it also can report capabilities. If the mobile supports only FBUS it should > try with a known minimum set of capabilities provided by > gnokii/gammu/phone-utopia. Why minimum? We want maximum! And look: that way we have the same device configured for: DBUS (to load a driver, configure device file, run an app etc), HAL, opensync (exceptions database), phone framework (capabilities over divverent drivers). That's IMO overengineered. > Not quite sure if gnokii already provides such fixed capabilities information > by protocol/model via the libgnokii API. But if not we could write for > gnokii-sync own capabilities files for certain devices and package them with > the plugin. It does (see common/misc.c), but: - it is hardocded currently - it isn't really maintained > > > Often the vendor software probes for the IMEI with AT+ commands. > > > (Not quite sure how the IMEI should be handled, since it's kind of > > > sensitive, isn't it?) > > > > It is. Additionally it can be changed (although it is illegal in some > > countries). On the other hand Nokia PC Suite uses IMEI as a phone > > identifier. > But this case shouldn't be supported... "This case"? take care, pkot -- Pawel Kot ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Daniel Gollub
::
Rate this Message:
On Thursday 01 November 2007 21:15:40 Pawel Kot wrote:
(Sorry for double post - attachment would increase the message body size up to 50k) > > Yeah, but those older phones which doesn't support SyncML nor IrMC should > > have nearly the same minimal set of capabilities - right? > > Depends on what level of granularity you define capabilities. The capabilities set of fields and the _max_ occur of those fields. > > > > Check /usr/share/hal/fdi/* > > > > Maybe a interesting example is > > /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi > > It fits exactly my needs. I'd like for every device having defined > which group of features does it support. For example: > <match key="usb.vendor_id" int="0x0421"> > <match key="usb.product_id" int="0x0428"> > <merge key="info.category" type="string">mobile_phone</merge> > <append key="info.capabilities" type="strlist">mobile_phone</append> > <merge key="mobile_phone.name" type="string">Nokia 6230i</merge> > <merge key="mobile_phone.syncml" type="string">yes</merge> Isn't USB_CDC_CLASS and USB_CDC_FBUS_SUBCLASS in combination with the vendor USB ID of Nokia enough? /* Nokia is the vendor we are interested in */ #define NOKIA_VENDOR_ID 0x0421 /* CDC class and subclass types */ #define USB_CDC_CLASS 0x02 #define USB_CDC_FBUS_SUBCLASS 0xfe I would suggest to write a hal preprobe callout application based on the dku2libusb.{c,h} code or something like that which got called if the Vendor and the CDC CALL and SUB CLASS matches. And take the data from the fbus_usb_interface struct and merge it into the Device FDI entry. So there is no need to write a hardcoded HAL FDI file. > <merge key="mobile_phone.connection" type="strlist">bluetooth</merge> > <append key="mobile_phone.connection" type="strlist">irda</append> Not quite sure if this is needed .. since the device wouldn't appear currently in HAL anyway. Bluetooth remote device aren't listed at the moment in HAL, same for IrDA - AFAIK. You should only feed HAL with data about currently connected devices... > <append key="mobile_phone.connection" > type="strlist">usb_dku2</append> <merge key="mobile_phone.driver" > type="strlist">AT</merge> This should be already available in HAL. HAL provides all information about the USB Interfaces and their sub classes. Example - Nokia 6230: dani@noname:~> lsusb -s067 Bus 001 Device 067: ID 0421:040f Nokia Mobile Phones 6230 GSM Phone If you run lshal ( http://cryptomilch.de/~dgollub/OpenSync/nokia6230.lshal ) you'll find something like: usb.interface.class = 2 (0x2) (int) usb.interface.number = 1 (0x1) (int) usb.interface.protocol = 1 (0x1) (int) usb.interface.subclass = 2 (0x2) (int) Subclass 0x2: AT Protocol (PCCA101) usb.interface.class = 2 (0x2) (int) usb.interface.number = 3 (0x3) (int) usb.interface.protocol = 0 (0x0) (int) usb.interface.subclass = 254 (0xfe) (int) Subclaass 0xfe: Likely a FBUS Interface if the Vendor is Nokia ;) So this data is already available without writing FDI files... > <append key="mobile_phone.driver" type="strlist">series40</append> > <merge key="mobile_phone.name" type="string">Nokia 6230i</merge> Couldn't we just probe for Name and other information? Most device get in meanwhile correctly announced: usb_device.product = '6230 GSM Phone' (string) usb_device.vendor = 'Nokia Mobile Phones' (string) > <!-- I am not sure at the moment if it would be required --> > <merge key="mobile_phone.series40.phonebook" > type="string">nokia_extended</merge> > <!-- vcard21, vcard30, nokia_dct3, nokia_series40, > nokia_series40_3rdEd, symbian, ... --> > <merge key="mobile_phone.AT.phonebook" type="string">vcard30</merge> We could write a preprobe callout which request x-obex/capabilities. Try "obexftp -u 0 -X" this is requesting x-obex/capabilities. Example from my Nokia 6230: http://cryptomilch.de/~dgollub/OpenSync/obex-capablities.xml This would be nice to get those information merged into HAL while the mobile get connected - without hardcoding it to a FDI file. > > Full agree, i often hit the problem even with Nokia mobiles and SyncML. > > We have to set/fake the identifier string for certain mobiles. On some > > mobiles it is "PC Suite" on other it's "PC Suite Data Sync" - otherwise > > the mobile reject with a "internal server error".... > > Yeah. And again, identifier could be a property for the device in HAL db. I thought about something for libsyncml, so it's not only limited to the platforms which running HAL. So libsyncml could be used with the correct identifiers also on Macosx and Windows. > > Did you really check vObject spec - is even this minimum set of > > capabilities to complex for older mobiles? > > I meant two things. This specification doesn't cover all my needs (ie. > phonebook, calendar are not enough). Old mobiles are not compliant > with VCARD21 (some of them). > But still: you need to know with which vCard specification a phone is > compliant. Where do you get this information from? I meant more general the fields which got described in vObject, not the format itself. Most mobiles still use vCard 2.1 .. so far i only saw some few newer Sony Ericsson mobiles which stores vCard 3.0 as well (but have vCard 2.1 as fallback). I guess thats the reason why they started to write a draft for vObject (the initial draft is from October 2007!). > > > > > OpenSync 0.3x has an own implementation to provide fixed > > > > capabilities. But we intend to make only use of fixed capabilities if > > > > it's really needed. For example if the firmware of the mobile is > > > > buggy, and can't store the ZIP code of the 3rd Address (like my Palm > > > > T|X) - so we overwrite the reported capability set of the device with > > > > a fixed set of capabilities which workaround this bug. But this is > > > > only in rare cases. > > > > > > But first you need to know, if the device supports ZIP code at all, > > > right? > > > > Correct... but beside FBUS most protocols really have fixed capabilities > > (like Palms only differ in two different - afaik) or you can request them > > (SyncML, IrMC, ...) > > Perhaps I don't know what I am taking about, but in this case it is > not SyncML but vCard2.1 or vCard 3.0 which define real capabilities. Not really in the case of SyncML - example: http://cryptomilch.de/~dgollub/OpenSync/devinf.example.xml > So I may prepare for myself some other specifications, like > NokiaPBook1.0, NokiaPBook2.0, .... And that's fine. I just would like > to have someone to tell me: Hey, some device got just connected. It > supports NokiaPBook 2.0 in FBUS mode and vCard 3.0 in obex mode. I'm not that familiar with FBUS, but with x-obex/capabilties it's possible - http://cryptomilch.de/~dgollub/OpenSync/obex-capablities.xml Do you have some specs/references or whatever about FBUS? Maybe we could improve the FBUS protocol implementation and allow to detect which format is used on the other end... > > If SyncML has an option to ask for capabilities that's great. Just > remember that claiming being compatible with spec, doesn't mean being > compatible. So I still think you will need some database for the > exceptions. We have some facilities in OpenSync to workaround that... just write a capabilties.xml for the device and place a description.xml (like in the previous mail). So it skips the devinf from the device.. since the capabilities files have _always_ higher priority then the device requested once. > > Why minimum? We want maximum! Oops, correct. > And look: that way we have the same > device configured for: DBUS (to load a driver, configure device file, > run an app etc), HAL, opensync (exceptions database), phone framework > (capabilities over divverent drivers). That's IMO overengineered. D-Bus is just the IPC used by HAL ... it doesn't play any further role in this game. OpenSync doesn't have the exceptions database, only the plugins. And the plugins only needed manually generated capabilities files if the protocol implementation which is the plugin based on doesn't provide this information. With protocol implementation i mean for example: libsyncml, gnokii, synce (librapi), libpisock (pilot-link), IrMC (plain libopenobex), ... HAL could make use of them, with little callout application for example, which do the discovery of the capabilities, or some necessary probing to identify the device. And then merge those information into the device fdi .. so the appear in the HAL FDI tree - during runtime! I think about having this callout application: obex_callout: Request just x-obex/capabilities and merge it into the obex interface fdi of HAL. That's enough to identify that SyncML or IrMC is available. The capabilities discovery for each objtype could be done easily with application which are based on libsyncml and openobex (for IrMC). In case of OpenSync this is planned for the IrMC and SyncML plugin... I'm not aware of any other used IrMC and SyncML implementation whihc makes use of OpenOBEX and libsyncml so far... If the obex_callout probe results something it should merge sync.protocol = [ "syncml-obex", "irmc" ] sync.syncml.version = [ "1.0", "1.1", "1.2" ] sync.syncml.format = [ "wbxml", "xml" ] palmhotsync_callout: Make use of libusb transport code from libpisock to probe if the USB Interface is an active HotSync interface. And merge something like this: sync.protocol = [ "palm-hotsync" ] Capabilities shouldn't be needed since there are only two different formats for contacts and events. Addressbook(old), ContactDB(new) and Datebook(old), Calendar(new) .. or something like that. First check if one of the newer databases exists, fallback if they don't exist ... capabilities are fixed for old and new databases. fbus_callout: Use the dku2libusb and check if the usb interface fits. sync.protocol = [ "fbus" ] But in this case your might be right... since you can't get any data from you might need to hardcode most capabilities. But the big advantage is if you stay with your "capabilities" with in "misc/common.h" it's independent of HAL. You could use those information from "misc/common.h" during the probe from the fbus_callout and merge them into HAL. So gnome-phone-manager, kontact and gnokii-sync and other libgnokii based application could benefit from that. > > > Not quite sure if gnokii already provides such fixed capabilities > > information by protocol/model via the libgnokii API. But if not we could > > write for gnokii-sync own capabilities files for certain devices and > > package them with the plugin. > > It does (see common/misc.c), but: > - it is hardocded currently Same if you would write it into as plain FDI file an place same into /usr/share/fdi/... > - it isn't really maintained Could be the same for HAL FDI files ;) And it's not portable to non-HAL platforms. > > > It is. Additionally it can be changed (although it is illegal in some > > > countries). On the other hand Nokia PC Suite uses IMEI as a phone > > > identifier. > > > > But this case shouldn't be supported... > > "This case"? I meant that someone changes the IMEI and break that the device can't be identified by his Sync setup or something like that.. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
|
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by Pawel Kot-5
::
Rate this Message:
Hi,
On 11/2/07, Martin Owens <doctormo@...> wrote: > 1) Mobile Phone functionality - We shouldn't be worried with or > including none syncing functionality in plugins for syncing (this is > just confirming) if a phone can act as a modem or a network device > that's great but let some other HAL callback handle that. I tend to disagree here. Please remember that if someone would want to use synchronization and file transfer and call dial and sms send, he/she would get access errors unless all access to the device is provided via layer that would synchronize the requests for the device. So focusing on synchronization is fine, but it must fit a bigger picture. take care pkot -- Pawel Kot ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by DoctorMO
::
Rate this Message:
> I tend to disagree here. Please remember that if someone would want to
> use synchronization and file transfer and call dial and sms send, > he/she would get access errors unless all access to the device is > provided via layer that would synchronize the requests for the device. > > So focusing on synchronization is fine, but it must fit a bigger picture. I also disagree with your point; the cost of incorporating the phone and networking functionality in the same scheme and project will be quite high, the lack of focus on syncing and the refocus on any old thing the phone happens to do with cause pain and slow down development. With conflict errors we have to be aware that the device access can be managed in HAL; your not going to be able to sync addressbook at the same time as sending an SMS and while we should be aware of functionality outside and attempt to be considerate; it would be unfortunate if the bigger picture you speak of is just the enabling of functionally for a single phone and not the big picture of being able to sync any pda or phone device through the same interface. Best Regards, Martin Owens ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by John Carr-3
::
Rate this Message:
On Fri, 2007-11-02 at 02:19 -0400, Martin Owens wrote:
> Hi, I'm not quoting as the topic is quite large so I'm making points > and then commenting: > > 1) Mobile Phone functionality - We shouldn't be worried with or > including none syncing functionality in plugins for syncing (this is > just confirming) if a phone can act as a modem or a network device > that's great but let some other HAL callback handle that. The plugins for syncing won't include such functions. You are right. A sync plugin should just sync. However, in enabling usb-rndis-lite you are also allowing windows phones to be used as an internet gateway. So you need to be aware of that and consider what to do - remove the part of the patch that allows this (boo!) or make sure that it doesnt break anything (in this case, the default of NetworkManager auto-configuring it is probably the ideal case anyway so its a moot point). Also, making effort *not* to ship supporting utilities (for example, SynCE has some kind of "VNC for phones" type feature) would be unfortunate... Especially when they are packaged and "just work" as a result of the other integration efforts. (I am keen to distance myself from the notion of shipping them by default though). > 2) In HAL fdi functionality we should be idenfiying things as > 'sync_point' or 'pim' not as 'mobile_phone' since Palm, WinCE, iPods > aren't phones (and ipods arn't even pims but we need to sync music, > photos and other things too) Agreed. > 3) All hardware talking to the computer should have HAL device nodes, > the callback code which is a fantastic idea needs to call the required > query code and add required information back to HAL; this includes a > unique identifying string of some kind, a space for refined model > (where more than one phone has the same usb device id) and a list of > capabilities that the sync plugin needs to do the right thing. Right. So a new WM device is plugged in. The eth* is dhcp'd and hal callout probes for more information - passing it back in to HAL property nodes. In theory this even allows for device-specific icons... Capabilities i'm not as sure about, especially as some devices need to actually sync to establish that information... > 4) The callback code can actually add functions to HAL, not just data. > so we can create a set of sync information and a sync end point code > hook which opensync could _very_ easily take advantage of to talk to > hardware without having to store so much. Don't understand. What is the advantage of this? Knowing which plugin to use should be enough? And remember that opensync has no desire to depend on HAL. > 5) OpenSync must be able to sync on the fly without requiring > configuration files; at the moment opensync's config requirements > holds it back from integration directly and offering the functionality > via dbus to tie a hardware node to another software data plugin is the > best option to allow us to create front ends that don't need to mess > about so much with config files (besides most of this config is going > to come from HAL and the information callbacks) Right. You can configure it via the API though. Conduit will take care of configuring much of this stuff. If it needs to come from the user or HAL, we will pass it in correctly. If its something that can be put in opensync (without HAL deps) we will. > 6) Where opensync does have configs they should be set up per end > point, not under a list of sync end points as is currently the case. > this would enable more than one phone to sync with kdepim without the > same kdepim config being duplicated. Could you elaborate on this point, i dont follow your meaning. > I've still yet to qrite up the notes from the meeting, my laptop is > suffering heat problems and it's not in a good state (it only has half > a gutsy install and the machine dies of overheating before the install > can finish) so anyway I will get my friend to grab the gobby text and > I'll run through it all. Unlucky :( My other laptop ocasionally needs its fans cleaning because of overheating. Generally there is 1cm of fluff wedged between the fan and heatsink :( Sucks! Could try powersave governor? John ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by DoctorMO
::
Rate this Message:
> The plugins for syncing won't include such functions. You are right. A
> sync plugin should just sync. However, in enabling usb-rndis-lite you > are also allowing windows phones to be used as an internet gateway. So > you need to be aware of that and consider what to do - remove the part > of the patch that allows this (boo!) or make sure that it doesnt break > anything (in this case, the default of NetworkManager auto-configuring > it is probably the ideal case anyway so its a moot point). I Agree, the functionality on the hw side should remain so long as these hw projects are not handled by the syncing platform project. > Capabilities i'm not as sure about, especially as some devices need to > actually sync to establish that information... Well if it's a new device, never before seen by the machine then we need not fill in the information but in these cases it should co-ordinate with the unique id and store information about the device to be used by hal once it's known. most times the information is available > Don't understand. What is the advantage of this? Knowing which plugin > to use should be enough? And remember that opensync has no desire to > depend on HAL. This is just a feature of HAL that it can optionally handle so you don't have to restrict the information to specific programs. for opensync this might not be a problem. > Right. You can configure it via the API though. Conduit will take care > of configuring much of this stuff. If it needs to come from the user or HAL, > we will pass it in correctly. If its something that can be put in > opensync (without HAL deps) we will. HAL should never be a requirement for opensync, but we should take advantage of it when it is. having a way to call the information callbacks directly may help with that for none HAL system. > > 6) Where opensync does have configs they should be set up per end > > point, not under a list of sync end points as is currently the case. > > this would enable more than one phone to sync with kdepim without the > > same kdepim config being duplicated. > Could you elaborate on this point, i dont follow your meaning. OK so you have a cofiguration for google pim (contacts/calendar) why should you need to configure your google password twice to sync directly from your nokia and to sync from your blackberry to your google pim? Best Regards, Martin Owens P.S. typing this on a AZERTY keyboard at UDS is interesting experence as I'm used to QWERTY ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: Ubuntu UDS-Boston, Syncing solutions
by John Stowers
::
Rate this Message:
>
> > > 6) Where opensync does have configs they should be set up per end > > > point, not under a list of sync end points as is currently the case. > > > this would enable more than one phone to sync with kdepim without the > > > same kdepim config being duplicated. > > Could you elaborate on this point, i dont follow your meaning. > > OK so you have a cofiguration for google pim (contacts/calendar) why > should you need to configure your google password twice to sync > directly from your nokia and to sync from your blackberry to your > google pim? At least in the GNOME case Conduit will probbably use information from online desktop to automatically configure certain 'endpoints' with a users account name, etc. This should provider a zero-configuration solution with certain endpoints John > > Best Regards, Martin Owens > > P.S. typing this on a AZERTY keyboard at UDS is interesting experence > as I'm used to QWERTY > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Opensync-devel mailing list > Opensync-devel@... > https://lists.sourceforge.net/lists/listinfo/opensync-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
signature.asc (196 bytes) | < Prev | 1 - 2 - 3 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
