On Sat, Jun 14, 2008 at 9:11 PM, Anders Feder <[EMAIL PROTECTED]> wrote:
> Olav, > > Thanks for your reply. I figured that people had read enough shiny use > cases, so I tried to keep those to a minimum, but sure. > > Let's say you use Evolution's address book to manage all your contacts > and you just bought a new smartphone which only supports a proprietary > address book format. You want to move your contacts to the new phone - > what do you do? Conduit has knowledge of which format is used by the > phone, but has no way to convert the data. This made me smile. I've just written the transport stuff needed for syncing Windows Mobile 5/6 with Conduit, but I need to convert AirSync XML to VCard and back before i'm finished. > Today, chances are that you will have to do something like exporting the > Evolution address book to the .vcf (vCard) format and then searching for > and downloading an application which is able to convert from .vcf to the > proprietary format and then finally move over the converted file to the > phone. Most likely, coming up with the steps involved in this task is > either too complex or too boring for many users. I agree that writing things to convert to and from vCard, iCal and others is the boring part of Conduit :-D If you can solve this problem for me I will buy you beer. > Now let's say that Evolution store its address book in the NEPOMUK > Contact Ontology (NCO) format in a central RDF repository and your new > phone support the Friend-of-a-Friend (FOAF) format. You do a query for > your Evolution contacts in Conduit and request them to be moved to the > phone. Conduit (or a lower level component) detects that the source and > destination formats differ, automatically search the Web for a matching > ontology alignment, map the NCO contacts into FOAF and move them to the > phone. > > RDF can automate many such processes, but a few components would be > required (or at least be very handy) at the system level such as a > central RDF repository and an ontology mapping service. One problem that you've skipped over is how Conduit learned to speak to the device in the first place. In this case i've written glue to link SynCE and Conduit, i would surely ship an AirSync ontology with Conduit, or get one shipped with SynCE, rather than depend on internet access to dynamically look one up? I think this might be nice for the formats and conversions problem, but it doesn't do anything for the transport problem. A generic dbus interface that we could badger applications to implement, or implement our selves via addins, would mean applications like Conduit could benefit without transport glue needing writing specifically for it. That combined with your solution for format conversion would be awesome. John
_______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
