http://bugzilla.moblin.org/show_bug.cgi?id=5188
--- Comment #4 from pohly <[email protected]> 2009-09-14 09:58:06 --- (In reply to comment #3) > (In reply to comment #2) > > > > Change EvolutionSyncClient::createTransportAgent, now adds a type > > > parameter to > > > indicate what type of transport will be created. Currently I am hard > > > coding it > > > to be OBEX_BLUETOOTH but should be dynamic later. I suggest add another > > > property at the server configuration (Transport Type = xxx). > > > > What about overloading the syncURL? We can use an HTTP transport for methods > > http:// and https:// and then add our own pseudo-URLs for other methods, > > like > > bluetooth://<MAC>:<channel> for outgoing OBEX via Bluetooth. > Adding the transport parameter have another effect: a transport can have > multiple implementations, we can choose one at runtime. (like HTTP_CURL and > HTTP_SOUP, which we currently make the selection during compile time). Hmm, perhaps. I can't think of any use case where the user would configure this inside the peer's configuration, though. A global setting "use GNOME" (= libsoup), "use KDE" (= ???), "use neither of these" (= libcurl) is more likely. This is similar to the problem of selecting the right keyring infrastructure: asking the user what to do is always only the second best solution. If we can't figure it out automatically, how is the GUI and the user supposed to know this? Remember, we are trying to provide a service for very inexperienced users. > Another thing is I haven't found URL schemes like > "bluetooth://<MAC>:<channel>", looks a little awkward... Feel free to suggest something better ;-} Please also have a look at my "configuration + multiple peers" email on the list. The relevant paragraph from that email is the following: | Each peer has its own peer-specific settings (credentials, URL and | transport) and source-specific settings (URI, sync mode). It might even | have more than one way of contacting it (Bluetooth, USB), although how | to handle this is a bit uncertain right now. My intention is to deal | with this inside the per-server config file instead of creating more | config files. Perhaps my approach is wrong and we really should have one peer configuration per transport, with shared meta data that is attached to the SyncML device ID once it is known? This could add the following files: .config/syncevolution/default/.devices/<device ID>/ .internal.ini sources/addressbook/ .internal.ini -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
