|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
features for gnome-sync in next two monthsHi,
I'm going to implement some new things for gnome-sync[1] in next two months, this includes: - HAL/DBUS support, auto detection and auto connection with existing groups. - Configuration GUI for palm-sync plugin. - Configuration GUI for libsyncml Plugin. - Object type config enhancement: allow user enable/disable/set_path per obj_type for each member - (optional) Configuration GUI for google calendar plugin. If you do not know gnome-sync, you could refer th GUI design doc on http://www.genunix.org/wiki/index.php/Opensync_new_gui_design [1] http://sourceforge.net/projects/gnome-sync Comments are welcomed! Thanks, Halton. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two monthsOn Monday 12 May 2008 13:33:15 Halton Huo wrote:
> Hi, > > I'm going to implement some new things for gnome-sync[1] in next two > months, this includes: > > - HAL/DBUS support, auto detection and auto connection with existing > groups. Thats really interesting! How do you plan to "map" a certain device which get announced via HAL (as connected) and the configured group/member? We had some discussion in the past about this ... The new OSyncPluginConfig Interface provides also a connection specific subcomponent: OSyncPluginConnection. You would have to load the OSyncGroupEnv step through all the member of each group and load the OSyncPluginConfig of the member and check for matching device in OSyncPluginConnection. I hope the information in OSyncPluginConnection are enough to identify those devices. If not please let me know, so we can enhance the interface for this... Once the OpenSync side got stabilized i hope i can do the same with KitchenSync, but using Solid, not speaking to HAL directly. Do you have any plans for bluetooth already? BlueZ provides for linux quite nice D-Bus API. (I have no idea about OpenSolaris and Bluetooth ...) > - Configuration GUI for palm-sync plugin. > - Configuration GUI for libsyncml Plugin. I would recommend to take a look on the the new OSyncPluginConfig interface. Since I plan to get rid of custom XML configurations - it would be nice if you could give me some feedback on the interface as well.. if there is anything missing or unhandy to write configuration GUIs.. > - Object type config enhancement: allow user enable/disable/set_path > per obj_type for each member > - (optional) Configuration GUI for google calendar plugin. The google calendar plugin should get rewritten first - iirc Christian had a look on this task. Christian, any update/progress here? > > If you do not know gnome-sync, you could refer th GUI design doc on > http://www.genunix.org/wiki/index.php/Opensync_new_gui_design > > [1] http://sourceforge.net/projects/gnome-sync ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two monthsOn Mon, 2008-05-12 at 23:47 +0200, Daniel Gollub wrote:
> On Monday 12 May 2008 13:33:15 Halton Huo wrote: > > Hi, > > > > I'm going to implement some new things for gnome-sync[1] in next two > > months, this includes: > > > > - HAL/DBUS support, auto detection and auto connection with existing > > groups. > > Thats really interesting! > > How do you plan to "map" a certain device which get announced via HAL (as > connected) and the configured group/member? We had some discussion in the > past about this ... > > The new OSyncPluginConfig Interface provides also a connection specific > subcomponent: OSyncPluginConnection. You would have to load the OSyncGroupEnv > step through all the member of each group and load the OSyncPluginConfig of > the member and check for matching device in OSyncPluginConnection. I hope the > information in OSyncPluginConnection are enough to identify those devices. If > not please let me know, so we can enhance the interface for this... > > Once the OpenSync side got stabilized i hope i can do the same with > KitchenSync, but using Solid, not speaking to HAL directly. > > Do you have any plans for bluetooth already? BlueZ provides for linux quite > nice D-Bus API. (I have no idea about OpenSolaris and Bluetooth ...) BZ stack is not in Solaris now. Someone inside Sun are working on it, AFAIK no plan. I may develop gnome-sync on Linux if need use bluetooth. > > > - Configuration GUI for palm-sync plugin. > > - Configuration GUI for libsyncml Plugin. > > I would recommend to take a look on the the new OSyncPluginConfig interface. > Since I plan to get rid of custom XML configurations - it would be nice if > you could give me some feedback on the interface as well.. if there is > anything missing or unhandy to write configuration GUIs.. Yes, you mentioned it on IRC. Will add this change. > > > - Object type config enhancement: allow user enable/disable/set_path > > per obj_type for each member > > - (optional) Configuration GUI for google calendar plugin. > > The google calendar plugin should get rewritten first - iirc Christian had a > look on this task. Christian, any update/progress here? Yep, can I have two requirement? - proxy support httplib2 support it. - save password safely, I hate plain text. gnome-keyring maybe a option, not know whether it can be used on KDE environment. Cheers, Halton. > > > > > If you do not know gnome-sync, you could refer th GUI design doc on > > http://www.genunix.org/wiki/index.php/Opensync_new_gui_design > > > > [1] http://sourceforge.net/projects/gnome-sync > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Opensync-devel mailing list > Opensync-devel@... > https://lists.sourceforge.net/lists/listinfo/opensync-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two monthsOn Tuesday 13 May 2008 03:28:13 Halton Huo wrote:
> > Do you have any plans for bluetooth already? BlueZ provides for linux > > quite nice D-Bus API. (I have no idea about OpenSolaris and Bluetooth > > ...) > > BZ stack is not in Solaris now. Someone inside Sun are working on it, > AFAIK no plan. I may develop gnome-sync on Linux if need use bluetooth. Maybe then you should plan to abstract your bluetooth GUI code to replace it on build time with D-Bus API of BlueZ or the Solaris Bluetooth stack. > > > > - Object type config enhancement: allow user enable/disable/set_path > > > per obj_type for each member > > > - (optional) Configuration GUI for google calendar plugin. > > > > The google calendar plugin should get rewritten first - iirc Christian > > had a look on this task. Christian, any update/progress here? > > Yep, can I have two requirement? > - proxy support > httplib2 support it. > - save password safely, I hate plain text. > gnome-keyring maybe a option, not know whether it can be used on KDE > environment. I hope this could be done with OSyncPluginAuthentication .. there is the attribute "reference" which is intended to store the ID of the key for Gnome key ring or KWallet. There is only some code missing so the plugin can request the password via this "ressource" without using specific key-ring implementation. I guess a new command for the OpenSync IPC is required, or just enhancing the connect command parameter. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two monthsOn Tue, 2008-05-13 at 07:45 +0200, Daniel Gollub wrote:
> On Tuesday 13 May 2008 03:28:13 Halton Huo wrote: > > > Do you have any plans for bluetooth already? BlueZ provides for linux > > > quite nice D-Bus API. (I have no idea about OpenSolaris and Bluetooth > > > ...) > > > > BZ stack is not in Solaris now. Someone inside Sun are working on it, > > AFAIK no plan. I may develop gnome-sync on Linux if need use bluetooth. > > > Maybe then you should plan to abstract your bluetooth GUI code to replace it > on build time with D-Bus API of BlueZ or the Solaris Bluetooth stack. > > > > > > > > - Object type config enhancement: allow user enable/disable/set_path > > > > per obj_type for each member > > > > - (optional) Configuration GUI for google calendar plugin. > > > > > > The google calendar plugin should get rewritten first - iirc Christian > > > had a look on this task. Christian, any update/progress here? > > > > Yep, can I have two requirement? > > - proxy support > > httplib2 support it. > > - save password safely, I hate plain text. > > gnome-keyring maybe a option, not know whether it can be used on KDE > > environment. > > I hope this could be done with OSyncPluginAuthentication .. there is the > attribute "reference" which is intended to store the ID of the key for Gnome > key ring or KWallet. There is only some code missing so the plugin can > request the password via this "ressource" without using specific key-ring > implementation. I guess a new command for the OpenSync IPC is required, or > just enhancing the connect command parameter. -Halton. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Opensync-devel mailing list > Opensync-devel@... > https://lists.sourceforge.net/lists/listinfo/opensync-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two months
On Mon, 2008-05-12 at 23:47 +0200, Daniel Gollub wrote:
Hi daniel, I took a look at the code of opensync_plugin_config.c. Currently, there are several APIs for the configuration of palm-sync and libsyncml plugin, but lack of APIs for the configuration of file/evolution plugin. For example, APIs to retrieve/store objtype/objformat supported by the plugin, path of the file/calendar/contacts/.... Now we can get these information through other APIs. But it's better to provide unified interfaces. Regards, Jedy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two monthsOn Tuesday 27 May 2008 09:41:27 Jedy Wang wrote:
> For example, APIs to retrieve/store objtype/objformat supported by the > plugin, path of the file/calendar/contacts/.... Now we can get these > information through other APIs. But it's better to provide unified > interfaces. Indeed ... we had a discussion about this few weeks/month ago. It's intended to make use of the "discovery" call to show all available resources with their objformat/objtype. And then let the UI present the available ressource the user and let decide which ressources (if multiple) to "enable", which get synced. http://thread.gmane.org/gmane.comp.misc.opensync.devel/2460/focus=2480 file-sync plugin is again special .. you have to configure the path. But this should be still possible with OSyncPluginRessource. Do you think this fits your need - or is something unclear/missing? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two months
On Tue, 2008-05-27 at 10:13 +0200, Daniel Gollub wrote:
Yes, we can use "discovery" to get available resources. But in some cases we just want to know the resources supported by certain plugin no matter they are available or not. Currently, I think I can get it from OSyncPluginInfo after calling osync_plugin_initialize.On Tuesday 27 May 2008 09:41:27 Jedy Wang wrote: > For example, APIs to retrieve/store objtype/objformat supported by the > plugin, path of the file/calendar/contacts/.... Now we can get these > information through other APIs. But it's better to provide unified > interfaces. Indeed ... we had a discussion about this few weeks/month ago. It's intended to make use of the "discovery" call to show all available resources with their objformat/objtype. And then let the UI present the available ressource the user and let decide which ressources (if multiple) to "enable", which get synced. Thanks, this fits my need.http://thread.gmane.org/gmane.comp.misc.opensync.devel/2460/focus=2480 file-sync plugin is again special .. you have to configure the path. But this should be still possible with OSyncPluginRessource. Do you think this fits your need - or is something unclear/missing? Jedy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two months
On Tue, 2008-05-27 at 16:54 +0800, Jedy Wang wrote:
On Tue, 2008-05-27 at 10:13 +0200, Daniel Gollub wrote:Yes, we can use "discovery" to get available resources. But in some cases we just want to know the resources supported by certain plugin no matter they are available or not. Currently, I think I can get it from OSyncPluginInfo after calling osync_plugin_initialize.On Tuesday 27 May 2008 09:41:27 Jedy Wang wrote: > For example, APIs to retrieve/store objtype/objformat supported by the > plugin, path of the file/calendar/contacts/.... Now we can get these > information through other APIs. But it's better to provide unified > interfaces. Indeed ... we had a discussion about this few weeks/month ago. It's intended to make use of the "discovery" call to show all available resources with their objformat/objtype. And then let the UI present the available ressource the user and let decide which ressources (if multiple) to "enable", which get synced. For example, if users want to create a new group using GUI. Actually, now the group dose not exist, so you can not discover it. Currently, we solve the problem by creating a temp group which is not a very good solution, I think. Regards, Jedy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
|
Re: [Opensync-users] features for gnome-sync in next two monthsOn Tuesday 27 May 2008 11:14:56 Jedy Wang wrote:
> > Yes, we can use "discovery" to get available resources. But in some > > cases we just want to know the resources supported by certain plugin > > no matter they are available or not. Currently, I think I can get it > > from OSyncPluginInfo after calling osync_plugin_initialize. I see your point - but i guess somewhen in future we'll have a lot of plugins which will be generic and not tied to any objformat/objtype. The SyncML plugin comes already very close to that... in theorey you can sync all kind of "objformats" with SyncML. You can even invent your own format (we might have to do this to support later cool OpenSync <-> OpenSync synchronization: using SyncML plugin and the xmlformat's with wbxml compression ... ;) ). So i wouldn't rely on that all plugins will report the correct number of objtypes/objformats. But i also see that something like this would be very helpful for usability on the UI side, to have some usable Wizards. Maybe we should introduce some plugin categories to solve this kind of problem: - PIM (services/applications tied to PIM e.g. evo2-sync,google-calendar,...) - Device - ... > For example, if users want to create a new group using GUI. Actually, > now the group dose not exist, so you can not discover it. Currently, we > solve the problem by creating a temp group which is not a very good > solution, I think. #0 Create Sync Profile/Group/or other term... #1 What to sync? (PIM) Application / Device? #2a ((PIM) Application) - List of PIM service/application plugins #2b (Device) - List of possible/supported connection types to detect a device: USB, Bluetooth, Network, .... #3 Add another Application/Device? - Goto #1 ... but i see your point here as well. There are some issues with the API and using plugins without the OSyncGroupEnv stuff. I guess it would be a lot easier if we could call discovery() for plugins + config without creating a OSyncMember struct. Any suggestions to change the API to make plugin more usable without OSyncGroupEnv are more then welcome. best regards, Daniel ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Opensync-devel mailing list Opensync-devel@... https://lists.sourceforge.net/lists/listinfo/opensync-devel |
| Free Forum Powered by Nabble | Forum Help |