Menu
▾
▴
opensync-devel — The place to coordinate the development of OpenSync
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(84) |
May
(18) |
Jun
(12) |
Jul
(6) |
Aug
(7) |
Sep
(10) |
Oct
(31) |
Nov
(59) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(53) |
Feb
(15) |
Mar
(43) |
Apr
(40) |
May
(63) |
Jun
(142) |
Jul
(54) |
Aug
(31) |
Sep
(30) |
Oct
(39) |
Nov
(36) |
Dec
(64) |
| 2007 |
Jan
(128) |
Feb
(261) |
Mar
(156) |
Apr
(127) |
May
(76) |
Jun
(131) |
Jul
(83) |
Aug
(124) |
Sep
(83) |
Oct
(88) |
Nov
(180) |
Dec
(90) |
| 2008 |
Jan
(86) |
Feb
(93) |
Mar
(117) |
Apr
(104) |
May
(65) |
Jun
(35) |
Jul
(38) |
Aug
(111) |
Sep
(58) |
Oct
(33) |
Nov
(102) |
Dec
(194) |
| 2009 |
Jan
(193) |
Feb
(74) |
Mar
(111) |
Apr
(77) |
May
(31) |
Jun
(20) |
Jul
(1) |
Aug
(3) |
Sep
(57) |
Oct
(125) |
Nov
(50) |
Dec
(3) |
| 2010 |
Jan
(26) |
Feb
(5) |
Mar
(13) |
Apr
(3) |
May
(3) |
Jun
(12) |
Jul
(27) |
Aug
(47) |
Sep
(105) |
Oct
(53) |
Nov
(34) |
Dec
(21) |
| 2011 |
Jan
(115) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(16) |
Jun
(15) |
Jul
(85) |
Aug
(21) |
Sep
(13) |
Oct
(12) |
Nov
(28) |
Dec
(23) |
| 2012 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(5) |
Aug
(31) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(9) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Chris F. <cd...@fo...> - 2010-08-24 19:11:21
|
On Sun, Aug 22, 2010 at 11:10:21AM -0400, griffin wrote: > is anyone still actively working on libsyncml? the majority of the > last thousand or so commits were from "bellmich", but there hasn't > been any activity for the last six months... > > bellmich, are you still active on this list? > is adding SWIG to libsyncml the clearly wrong thing to do? > any objections to my adding SWIG support to libsyncml? I have no objections, but I'm not a libsyncml developer. Maybe a direct CC is better to reach him. (added to this email) - Chris |
|
From: Chris F. <cd...@fo...> - 2010-08-24 19:01:18
|
On Fri, Aug 20, 2010 at 11:17:33PM -0700, Emanoil Kotsev wrote: > So as I understand the goal is to have akonadi plugin. Is the 0.4X > engine working the same way as the 0.2X. I can then imagine trying to > write a plugin that would sync a file with akonadi - using file-sync > and akonadi-plugin I consider the 0.4x engine to be just about as stable as 0.2x, and definitely worth porting plugins to. Neither is perfect, but at least 0.4x has a chance of being fixed if you find a bug. :-) - Chris |
|
From: griffin <gr...@ub...> - 2010-08-24 17:27:22
|
SVG uploaded, but as i noted in my comments, i'm not very experienced with inkscape, so for those that know how to effectively emulate a conical gradient, definitely please show me how! quentin, i do like your idea of adding arrows, so i'll give it a try as well. On Sun, 22 Aug 2010 20:24:25 -0400, Fernando Toledo <ft...@do...> wrote: > On Dom 22 Ago 2010 11:55:52 griffin escribió: >> just added another entry - the red/blue of the other two just makes me >> think of palm's hotsync, so wanted to try something to get away from >> that... thoughts? >> > i think that must be upload in svg format and make happy to use with > inkscape. |
|
From: Fernando T. <ft...@do...> - 2010-08-23 00:24:36
|
On Dom 22 Ago 2010 11:55:52 griffin escribió: > just added another entry - the red/blue of the other two just makes me > think of palm's hotsync, so wanted to try something to get away from > that... thoughts? > i think that must be upload in svg format and make happy to use with inkscape. -- Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar |
|
From: griffin <gr...@ub...> - 2010-08-22 15:22:53
|
just added another entry - the red/blue of the other two just makes me think of palm's hotsync, so wanted to try something to get away from that... thoughts? On Fri, 20 Aug 2010 17:45:30 -0400, Chris Frey <cd...@fo...> wrote: > On Thu, Aug 19, 2010 at 11:38:24PM +0200, Quentin Denis wrote: >> Hi folks, >> >> I was wondering if a it would be time for a new and fresh logo for >> OpenSync? >> In the context of the long awaited stable 0.40 it would be nice to >> fresh up >> the public image. This should also include the wiki I am working on. >> Check out >> this page and tell me if I can publish it in the news of the frontpage: >> http://www.opensync.org/wiki/LogoContest > > I don't mind a logo contest. Is the old logo the one at the top of the > main page? Include that in the contest too. > > As for your entry, I like version 2, but somehow the "O" seems like it > should > be more circular instead of oblong. > > Just my $0.02. > > - Chris > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: griffin <gr...@ub...> - 2010-08-22 15:10:40
|
is anyone still actively working on libsyncml? the majority of the last thousand or so commits were from "bellmich", but there hasn't been any activity for the last six months... bellmich, are you still active on this list? is adding SWIG to libsyncml the clearly wrong thing to do? any objections to my adding SWIG support to libsyncml? On Sun, 18 Jul 2010 00:10:06 -0400, griffin <gr...@ub...> wrote: > hi opensync-devel, > > i'd like to add SyncML support to a python-based web server, and > looked around for a python syncml library, but could not find > anything very promising. so have started toying with the idea of > adding a SWIG wrapper to your libsyncml. being completely > unfamiliar with the architecture, i am not sure if this is the > right approach and wanted your guidance here... some questions: > > - is there a better way or a library that you are aware of that > would be better suited? > > - since the request will be received by python, can libsyncml be > used in such a way that it is not actually listening to the > socket, but is instead invoked with an open data stream? > > any help appreciated and i hope that i can contribute useful > code via SWIG so that as many languages as possible can easily > use libsyncml! > > thanks in advance, > griffin > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: Mark E. <ma...@mp...> - 2010-08-22 09:34:41
|
On Sun, 2010-08-22 at 00:17 +0200, Daniel Gollub wrote: > On Sunday, August 22, 2010 04:09:35 am Mark Ellis wrote: > > In short, the problem seems to be in OSyncList memory allocation, which > > uses GSlice. I've pretty much figured out that the code using OSyncList > > and therefore GSlice runs through once ok, but falls over the second > > time around. If I had to guess, I would say that something is > > reinitialising the slice allocator unsafely in another thread, but I'm > > guessing wildly. > > Could you provie for this issue a small demo application using OSyncList to > reproduce the problem? I would look into that then .. > Hi Daniel I don't believe it's OSyncList specifically, but instead something to do with threading and initialisation of the slice allocator. If you want to reproduce it, just set up a sync group containing the python sample plugin, all latest svn, and run a discover on it with osynctool, you'll get a sugfault. Now run it again with G_SLICE=always-malloc and it won't segfault. It won't work either, but that's an entirely different problem ! I've done a lot of analysis, rebuilding libopensync and glib with extra logging, and at some point the slice allocator is getting a completely bizarre and invalid address to allocate from. This address is then passed out into an OSyncList allocation request and segfaults. I'm going away for a couple of weeks today, but I'll try and sort out my notes and send them on. Mark |
|
From: Daniel G. <go...@b1...> - 2010-08-21 22:18:10
|
On Sunday, August 22, 2010 04:09:35 am Mark Ellis wrote: > In short, the problem seems to be in OSyncList memory allocation, which > uses GSlice. I've pretty much figured out that the code using OSyncList > and therefore GSlice runs through once ok, but falls over the second > time around. If I had to guess, I would say that something is > reinitialising the slice allocator unsafely in another thread, but I'm > guessing wildly. Could you provie for this issue a small demo application using OSyncList to reproduce the problem? I would look into that then .. Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner Linux Consultant & Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Mark E. <ma...@mp...> - 2010-08-21 16:09:45
|
Hi All A little while ago, I was trying to get the python bindings and plugin working for 0.39/0.40, mainly for the synce project. Because of time constraints I pretty much gave up with a particular problem, but there seems to be a bit more activity around so I guess it's time to revisit and see if anyone can help. In short, the problem seems to be in OSyncList memory allocation, which uses GSlice. I've pretty much figured out that the code using OSyncList and therefore GSlice runs through once ok, but falls over the second time around. If I had to guess, I would say that something is reinitialising the slice allocator unsafely in another thread, but I'm guessing wildly. I know it's in the slice allocator, because if I run with G_SLICE=always-malloc, causing it to use a straight malloc, I don't get a segfault. I've run around in circles on this one, hoping someone can provide some insight. Thanks Mark |
|
From: Graham C. <g+o...@co...> - 2010-08-20 22:35:47
|
On Friday 20 August 2010 22:56:45 Chris Frey wrote: > The engine is quite usable, but the plugins are lagging behind. There are a number of open bug reports. From my recollection, I am not quite sure if the timeout issue in the engine is solved, but I think the queue limit is still disabled so it doesn't stop anything working today unless you have a very large number of entries. If I remember correctly, the most obvious outstanding problem which stops people actually using opensync (apart from porting more of the plugins) is the lack of timezone handling (and possibly some other issues) in the vformat plugin. However, the more serious issue is capabilty handling which is generally missing: it doesn't affect basic sync but will cause data loss if people try to use opensync for production use. > The > most up to date plugins, in my personal experience, are barry-sync > and evo2-sync. From what I've seen, the most consistent work has > also been on file-sync and the syncml plugin. gpe-sync is not currently working but I don't think it will take me long to fix it. But it won't be until I get back from holiday in a couple of weeks. Graham |
|
From: Chris F. <cd...@fo...> - 2010-08-20 21:56:55
|
On Wed, Aug 18, 2010 at 01:38:20PM -0700, Emanoil Kotsev wrote: > What I understood from this e-mail is that 0.40 is pretty ready for > use. Is it? The engine is quite usable, but the plugins are lagging behind. The most up to date plugins, in my personal experience, are barry-sync and evo2-sync. From what I've seen, the most consistent work has also been on file-sync and the syncml plugin. Please test and report specific error messages or issues that you run into. I don't have a syncml phone to test with, so my experience there is very limited. - Chris |
|
From: Chris F. <cd...@fo...> - 2010-08-20 21:45:40
|
On Thu, Aug 19, 2010 at 11:38:24PM +0200, Quentin Denis wrote: > Hi folks, > > I was wondering if a it would be time for a new and fresh logo for OpenSync? > In the context of the long awaited stable 0.40 it would be nice to fresh up > the public image. This should also include the wiki I am working on. Check out > this page and tell me if I can publish it in the news of the frontpage: > http://www.opensync.org/wiki/LogoContest I don't mind a logo contest. Is the old logo the one at the top of the main page? Include that in the contest too. As for your entry, I like version 2, but somehow the "O" seems like it should be more circular instead of oblong. Just my $0.02. - Chris |
|
From: Chris F. <cd...@fo...> - 2010-08-20 21:26:22
|
On Thu, Aug 19, 2010 at 11:29:18PM +0200, Quentin Denis wrote: > These are only broken parts that are about 2 years old, what about new > functions that I am not aware of and that I should integrate in kitchensync? > Fixing and eliminating broken functions may make kitchensync compile but what > if it lacks the new features of 0.4? Enlighten me, please! The main extra step in 0.4x is discovery. It must be done before the sync itself. You can find the code to do that in osynctool. > callbackhandler.cpp: does not compile (invalid conversion and itializing > argument error around the lines 136-139) > > pluginenv.cpp: > osync_plugin_env_free( mPluginEnv ); > osync_plugin_env_num_plugins( mPluginEnv ); > -> what now? "free" style calls are now "unref" calls, so osync_plugin_env_free() becomes osync_plugin_env_unref(), to emphasize that these are shared pointers. > filter.cpp: > I could make it compile by including > <opensync/opensync_filter_internals.h> but I think it is not part of 0.4. What > does it lead to? What are the consequences? The headers called "internal" or "private" will not be found in the library itself. It may get past the compile stage, but you'll have trouble during linking. > group.cpp: > osync_group_set_last_synchronization( mGroup, dateTime.toTime_t() ); > -> completely removed? No alternative? It is used by kitchensync at the > following place: > case QSync::SyncEngineUpdate::Successful: > mStatus->setText( i18n( "Successfully synchronized" ) ); > mSyncProcess->group().setLastSynchronization( > QDateTime::currentDateTime() ); > mSyncProcess->group().save(); > > osync_group_num_members( mGroup ); osync_group_nth_member( mGroup, pos ); > osync_group_num_filters( mGroup ); osync_group_nth_filter( mGroup, pos ); > -> are they replaced by OSyncList *osync_group_get_members(OSyncGroup *group); > ? So I now try to catch the nth OSyncList item, right? Quite an evidence, but > it's just to make sure! ;) You don't have to set the last sync time anymore. Opensync records the timestamp automatically when you do sync, and you can grab it with osync_group_get_last_synchronization(group); > syncmapping.cpp > osync_mapping_engine_nth_change, _num_, etc > -> same logic as above I guess I believe most of the "nth" style functions have been removed in favour of giving you an OSyncList and letting you find it yourself in the form of a for loop. :-) See the plugin porting email I sent earlier. > syncchange.cpp: > opensync/file.h does not exist anymore and makes OSyncFileFormat > undefined Not sure about this. > syncupdates.cpp: > all the events (ex: OSYNC_MAPPING_EVENT_SOLVED) are broken, what have > they been replaced by? They have been renamed and possibly recategorized. See the osynctool source code and search for "EVENT_SOLVED". You'll see callback functions listed there with switch statements with the new names. - Chris |
|
From: Quentin D. <que...@gm...> - 2010-08-19 21:42:33
|
Hi folks, I looked at the libqopensync code that is used by kitchensync to translate the library into Qt. It's a very basic and simple translation from C to Qt, but changes in the API broke this libqopensync. I am trying to fix the lines but since I have absolutely no idea of the API I would like to get my changes revised and to understand the implications and consequences of those changes (see below). These are only broken parts that are about 2 years old, what about new functions that I am not aware of and that I should integrate in kitchensync? Fixing and eliminating broken functions may make kitchensync compile but what if it lacks the new features of 0.4? Enlighten me, please! I think it would be better to maintain that library in opensync's svn and not outside at KDE's. Would you clone this repo (or give me the rights to commit to svn and do these changes by myself): http://websvn.kde.org/trunk/playground/pim/kitchensync/libqopensync/ The following files do not compile properly: (notice: I created a symlink from opensync/ to libopensync1/opensync/ to workaround the path change in the includes) callbackhandler.cpp: does not compile (invalid conversion and itializing argument error around the lines 136-139) pluginenv.cpp: osync_plugin_env_free( mPluginEnv ); osync_plugin_env_num_plugins( mPluginEnv ); -> what now? filter.cpp: I could make it compile by including <opensync/opensync_filter_internals.h> but I think it is not part of 0.4. What does it lead to? What are the consequences? group.cpp: osync_group_set_last_synchronization( mGroup, dateTime.toTime_t() ); -> completely removed? No alternative? It is used by kitchensync at the following place: case QSync::SyncEngineUpdate::Successful: mStatus->setText( i18n( "Successfully synchronized" ) ); mSyncProcess->group().setLastSynchronization( QDateTime::currentDateTime() ); mSyncProcess->group().save(); osync_group_num_members( mGroup ); osync_group_nth_member( mGroup, pos ); osync_group_num_filters( mGroup ); osync_group_nth_filter( mGroup, pos ); -> are they replaced by OSyncList *osync_group_get_members(OSyncGroup *group); ? So I now try to catch the nth OSyncList item, right? Quite an evidence, but it's just to make sure! ;) syncmapping.cpp osync_mapping_engine_nth_change, _num_, etc -> same logic as above I guess syncchange.cpp: opensync/file.h does not exist anymore and makes OSyncFileFormat undefined syncupdates.cpp: all the events (ex: OSYNC_MAPPING_EVENT_SOLVED) are broken, what have they been replaced by? So far so good! Thanks for your help! -Quentin |
|
From: Quentin D. <que...@gm...> - 2010-08-19 21:41:33
|
Hi folks, I was wondering if a it would be time for a new and fresh logo for OpenSync? In the context of the long awaited stable 0.40 it would be nice to fresh up the public image. This should also include the wiki I am working on. Check out this page and tell me if I can publish it in the news of the frontpage: http://www.opensync.org/wiki/LogoContest Daniel, could you give me administrative rights on Trac? I'd like to make bigger changes and to manage the tickets, too. The more rights you give me the more I can work and contribute. Kind regards, Quentin |
|
From: Quentin D. <que...@gm...> - 2010-08-18 21:16:52
|
Hello Emanoil, I am happy to read your email. Me too, I am a recently jump-in contributor who tries to make things move on. According to me, the most important plugin missing to get opensync back on trac is the Akonadi plugin. If you are a KDE user, you will value this plugin more than anything else. There had been a try, some time ago, but it has then been stopped because of the constant change in the opensync API. Now that the API is stable, you could try to pick it up: http://websvn.kde.org/trunk/KDE/kdepim/runtime/opensync/ ...or you start from scratch! ;) Chris Frey recently write a plugin porting howto for the latest svn, I put it online: http://www.opensync.org/wiki/devel/pluginPortingGuide-0.40 I suppose that you know where to find the Akonadi API documentation, but if you need guys to help out I can give you some contacts. If you prefer to start with something else, Chris will tell you to continue to port the broken plugins. On my side I am hacking on kitchensync and its libqopensync, but more on that later. Kind regards and thanks, Quentin On Wednesday 18 August 2010 22:38:20 Emanoil Kotsev wrote: > --- On Tue, 8/17/10, Chris Frey <cd...@fo...> wrote: > > From: Chris Frey <cd...@fo...> > > Subject: Re: [Opensync-users] Fwd: Google plugin for opensync > > To: "Quentin Denis" <que...@gm...> > > Cc: ope...@li..., eha...@ra..., > > ope...@li... Date: Tuesday, August 17, 2010, > > 4:44 AM > > On Sat, Aug 14, 2010 at 10:04:51AM > > > > +0200, Quentin Denis wrote: > > > I have followed the discussion "SCM changes"; but I > > > > prefer to reply in this > > > > > thread since my contribution to the topic is not of a > > > > valuable experience. > > > > > All I notice is that you have a serious API and/vs > > > > Plugin problem, probably > > > > > also source of all wilting on contributor's side. > > > > Probably true. But there's some resistance, and it is > > not critical > > to a 0.40 release. I can hack around it. > > > > Here is what I think is needed for a 0.40 release: > > > > 1) Developer documentation on how to compile the library, > > osynctool, and > > all plugins... perhaps with helper > > scripts to automate this. > > I am willing to share my setup details, > > if you want to document > > this. Currently I have opensync, > > osynctool, evolution2, > > barry-sync, file-sync, google-calendar, > > vformat, and xmlformat > > setup to compile very regularly. > > More is better, but I'm currently > > working on google-calendar. > > > > A lot of work was done recently on > > ldap-sync, so I'm suspecting > > that ldap support is good, but I haven't > > had a chance to test it yet. > > You are addressing many questions.I'm personally _very_ disappointed that > syncing with linux is still not possible at least for me. I am thinking of > testing opensync (compile from source) and I need only three plugins kde, > gnome and syncm (basically for a nokia phone) > > I'm very experienced in coding, documenting and QA-ing (testing) as I am > doing this on professional basis, so I'm willing to get somehow this > working and possibly share my experience. > > What I understood from this e-mail is that 0.40 is pretty ready for use. Is > it? May be I could focus on the kde part. It's really annoying that there > is no way to sync my phones. Where do I start best? I've looked around the > project and started reading the whitepaper. As far as I see it is > targeting kde 4. Is it true or I can try compiling svn code on kde 3.5? > > Don't understand me wrong. I recognize the complexity of the issue and have > a respect from your work, but since recently syncml is being widely used > and google is also a big player I'm wondering how are the priorities set. > > kind regards and thanks in advance |
|
From: Chris F. <cd...@fo...> - 2010-08-17 02:44:56
|
On Sat, Aug 14, 2010 at 10:04:51AM +0200, Quentin Denis wrote: > I have followed the discussion "SCM changes"; but I prefer to reply in this > thread since my contribution to the topic is not of a valuable experience. > All I notice is that you have a serious API and/vs Plugin problem, probably > also source of all wilting on contributor's side. Probably true. But there's some resistance, and it is not critical to a 0.40 release. I can hack around it. Here is what I think is needed for a 0.40 release: 1) Developer documentation on how to compile the library, osynctool, and all plugins... perhaps with helper scripts to automate this. I am willing to share my setup details, if you want to document this. Currently I have opensync, osynctool, evolution2, barry-sync, file-sync, google-calendar, vformat, and xmlformat setup to compile very regularly. More is better, but I'm currently working on google-calendar. A lot of work was done recently on ldap-sync, so I'm suspecting that ldap support is good, but I haven't had a chance to test it yet. 2) Port all plugins. In addition to the ones listed above, I would add the following as important plugins to port: kdepim mozilla / thunderbird / sunbird (probably just needs testing of the bluezync project) syncml What others are people interested in? 3) I'm not familiar with the defects that must be fixed in 0.39 before 0.40 can be released, so I'd guess that if all the above plugins work for people, then we're quite ready for 0.40. I'd hesitate to release 0.40 before then, because people will expect solid API stability in 0.40, and that would be foolish to publish before the plugins have been tested by regular folks. One part that should get cleaned up is the group of failed tests in the opensync library. I don't fully understand all of them, but some look like simple directory / path issues. I could use some help on weeding out the serious from the simple failures. I posted a plugin porting document in a previous email. Quentin, would you like to put that on the wiki? If anyone wants to jump in and port a plugin, I'd be happy to help answer library questions to the best of my knowledge. Just post to the mailing list. Once the plugins are working, we should release a set of 0.39.1 tarballs to the public, and let people test them for a week or so. If all is well, release 0.40. > - give yourself and the users DEADLINES!!!, publish them on the roadmap. > Users want to know release dates, or they get discouraged! Working on google-calendar has taken much longer than I thought it would, so deadlines would just frustrate me. :-) I'd rather have a clear list of what needs to be done for 0.40. I'm not sure that exists, except as a pile of issues in the tracker. There are a lot of items such as "Public API 0.40 review of opensync/archive" which, in my opinion is another way of saying "port all plugins and make them work." :-) If the plugins work, the API is as good as it needs to be for 0.40. We shouldn't be stingy with version numbers. Release early and often. > That's not even the beginning, I currently have no time and will start only > in one week to work on the wiki page, i.e. homepage. I will fresh it up, but > maybe I will require some admin rights (my username is "denisq"). For > example, the search function is broken, let me fix it, let me bring some > bigger changes to, give me access to the sources. I'm not an admin, so if you need more rights, Daniel will have to make the adjustments. > If you have a google account, you will see that gmail is now featuring > "Tasks". I don't know if Adenilson already implemented it, but it is not one > of the most important features right now. We'll come back to that one later, > Contact and Calendar is far more important. Yeah, I see tasks now. It is not implemented in libgcal yet, AFAIK. > Nice, it will make me and others happy. ...even if it is only a fraction of > happiness compared to the apparition of an Akonadi plugin! ;) Maybe I should add that plugin to the list too, but I know so little about Akonadi. I could use a serious education on it. - Chris |
|
From: Chris F. <cd...@fo...> - 2010-08-16 20:33:25
|
Hold the phone... Google (or the plugin) thinks that modification is addition in some cases, so there's some issues to be worked out yet. - Chris On Mon, Aug 16, 2010 at 03:03:09PM -0400, Chris Frey wrote: > Hi list, > > I've made some changes to the library, the google-calendar plugin, and > the vformat plugin, which now supports calendar event syncing. > > The most tricky part was that opensync uses ISO 8601 *without* separators > and without timezone offsets, while Google uses ISO 8601 only *with* > separators and with optional timezone offsets. > > I could have done this conversion inside the google-calendar plugin alone, > but this kind of timestamp manipulation seemed like useful code to share, > so I updated the library and the vformat plugin to do conversions if > necessary. > > This means that if you feed opensync an XMLFormat document that happens > to contain ISO 8601 timestamps with a timezone offset, opensync will > automatically convert it to opensync timestamp format, and convert > the timezone information into a UTC timestamp, since timezone support > in vformat is not yet complete. It also works in the other direction: > an invalid vformat object with ISO 8601 timestamps + timezone offset > will be converted to opensync timestamps in UTC. > > If no timezone offset is found, then just the dashes and colons are removed, > as before, but this time in both xml -> vformat and vformat -> xml > directions, instead of just vformat -> xml as before. > > Now that calendar syncing with google-calendar in the preliminary "working" > state, I plan to continue testing it, and fix up the contact syncing side > as well. > > Please report any problems you find to the mailing list. > > Thanks, > - Chris > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: Chris F. <cd...@fo...> - 2010-08-16 19:03:18
|
Hi list, I've made some changes to the library, the google-calendar plugin, and the vformat plugin, which now supports calendar event syncing. The most tricky part was that opensync uses ISO 8601 *without* separators and without timezone offsets, while Google uses ISO 8601 only *with* separators and with optional timezone offsets. I could have done this conversion inside the google-calendar plugin alone, but this kind of timestamp manipulation seemed like useful code to share, so I updated the library and the vformat plugin to do conversions if necessary. This means that if you feed opensync an XMLFormat document that happens to contain ISO 8601 timestamps with a timezone offset, opensync will automatically convert it to opensync timestamp format, and convert the timezone information into a UTC timestamp, since timezone support in vformat is not yet complete. It also works in the other direction: an invalid vformat object with ISO 8601 timestamps + timezone offset will be converted to opensync timestamps in UTC. If no timezone offset is found, then just the dashes and colons are removed, as before, but this time in both xml -> vformat and vformat -> xml directions, instead of just vformat -> xml as before. Now that calendar syncing with google-calendar in the preliminary "working" state, I plan to continue testing it, and fix up the contact syncing side as well. Please report any problems you find to the mailing list. Thanks, - Chris |
|
From: Chris F. <cd...@fo...> - 2010-08-16 00:34:36
|
Hi, In trying to run the opensync tests, I find a number of them that seem to fail for simple file or directory errors. This leads me to believe that I'm not running the tests correctly. I'm currently creating a build/ subdirectory for cmake, and building there. Then running 'make test' after a build and install. Is this correct? Test 278 (context_uid_update) fails in this regard, and it fails at a simple system call for 'cp testdata blah'. Surely I'm doing something wrong. Thanks, - Chris |
|
From: Quentin D. <que...@gm...> - 2010-08-14 08:04:59
|
On Fri, Aug 13, 2010 at 11:09 PM, Chris Frey <cd...@fo...> wrote: > > > I quite agree with the above, and I think the first step in fixing this > situation is to bring all the engine and plugin sources together into > one SVN or git repository, and get rid of the SVN externals stuff, which > makes it harder to interface with other SCM software. > > If it is possible for a developer to make a change in the engine, and > run 'make' and automatically compile all plugins and thereby test that > the API has at least been updated for all plugins, I think development > would be smoother. Sort of like how the linux kernel has all the modules > included, and if you change the kernel, the modules break automatically, > and the compiler helps you update things. > > > ATTENTION anyone reading this thread: please let me know if this will cause > trouble that I don't foresee. I plan to update at least the opensync SVN > to get rid of its externals if possible, and put all plugins into it. > > I have followed the discussion "SCM changes"; but I prefer to reply in this thread since my contribution to the topic is not of a valuable experience. All I notice is that you have a serious API and/vs Plugin problem, probably also source of all wilting on contributor's side. In my opinion: - engine and plugins should be maintained together, anyone who changes the engine breaking the plugins should fix the latter - plugins should be released with the engine; it makes to sense to have an engine without plugins. If a user's favorite plugin is not shipped with the release, the suite is useless for him. (imagine Linux kernel release with missing modules...) - you can put plugins and engine together in a tarball (and in the trunk) because they belong together (see point above). It will also be easier to see which ones are broken. Furthermore, it should not be a problem for packagers, even if the transition would require to rewrite the spec file(s), the result would be easier to maintain. I am a (former?) packager and know how to deal with that, all this being my personal opinion. - don't waste time on developer's environment changes or details, forget about porting svn to git; don't waste time on CDash and automated testing environments, hurry up to bring FINALLY the stable 0.4 version. - give yourself and the users DEADLINES!!!, publish them on the roadmap. Users want to know release dates, or they get discouraged! > > I see you've already updated the wiki... nice! Thanks! > That's not even the beginning, I currently have no time and will start only in one week to work on the wiki page, i.e. homepage. I will fresh it up, but maybe I will require some admin rights (my username is "denisq"). For example, the search function is broken, let me fix it, let me bring some bigger changes to, give me access to the sources. > You also mentioned "tasks" in your earlier email... I can see libgcal API > for contacts and calendar, but not sure about tasks. > If you have a google account, you will see that gmail is now featuring "Tasks". I don't know if Adenilson already implemented it, but it is not one of the most important features right now. We'll come back to that one later, Contact and Calendar is far more important. > I'm close to committing some patches to the google-calendar plugin > that gets calendar working nicely again. Just have to hammer out some > timestamp conversion issues. Nice, it will make me and others happy. ...even if it is only a fraction of happiness compared to the apparition of an Akonadi plugin! ;) Please give us release dates for beta, RC and final stable 0.4! |
|
From: Michael B. <mb...@de...> - 2010-08-14 03:18:36
|
Hi, On Sat, Aug 14, 2010 at 12:22:10PM +1200, Daniel Gollub wrote: > Another problem might be the difference licenses. > > libopensync is LGPLv2 > I guess most of the plugins are GPLvX or something else but in most cases not > LGPLv ... something which packager might not like as well. I don't think that is a problem, I believe there are lots of library/program combinations where the library is LGPL and the programs using it are GPL and they are released in the same tarball. >From the Debian/Ubuntu side, you just have to specify which license belongs to which files/directories. That said, having everything in one tarball would be problematic release-wise, as changes in some plugin would require a release process for the whole opensync suite. I understand that so far there has been exactly one release for each (ported) module for a particular opensync release and both happened at the same time, but I think this is the single most biggest flaw in the current process - plugins should get released when there are ported to a new opensync release, they should not hold up a release, nor have to play endless catch-up to opensync Once a plugin misses a release and gets ported in svn, changes in the main module might break it again, making it possibly miss another release. I believe plugins should by more freely released (and possibly getting additional 0.39.1 etc. releases if problems are found and fixed against that version of opensync in the plugin later on. Michael |
|
From: Chris F. <cd...@fo...> - 2010-08-14 00:53:09
|
Hi Daniel, Thanks for your response! On Sat, Aug 14, 2010 at 12:22:10PM +1200, Daniel Gollub wrote: > I guess this would break our test automation we have running currently: > > http://opensync.org/testing/ Interesting items that I didn't realize existed. :-) > And so far we only have one single svn:externals - and it's just for the cmake > modules. Yeah, it's sad that this breaks git and others ... but the cmake- > modules doesn't change that often. Actually we introduced that due to the fact > that cmake and it's modules were still in a very early stage of development. > So we had to write a couple of cmake modules by our own to find buliding > depencies ... i guess some modules find their way already in recent cmake > versions which already packaged in recent distribution. So we could think of > getting replacing svn:externals by merging the changed modules - if required. > > How does that sounds to you? > You might wanna try this for those repositories you're actively using - e.g. > opensync, osynctool(?), google-calendar, file-sync, ... so you can use for > those at least a git bridge. I'm using git already, and have a git-svn clone of the cmake modules as well, using git submodules to handle it. It is total hackery and a pain in the backside, but it works, and I can use git instead of svn. :-) I'd only want to remove the externals if we were going to include the plugins in the opensync tree. This way the cmake-modules would already exist, could be easily shared, and no externals would be needed. But with separate svn trees for each plugin, it makes sense to share the cmake modules too. > Regarding moving all plugins into one repo ... > > > The Distribution packager might not be happy about that ... > Since this would be heavy packaging change. I'd be interested in seeing things made easier for the packagers. It should be possible to just change the svn checkout command, and cd opensync/plugins/<myplugin> and do the same thing as before. > Another problem might be the difference licenses. > > libopensync is LGPLv2 > I guess most of the plugins are GPLvX or something else but in most cases not > LGPLv ... something which packager might not like as well. I hadn't thought of that. I don't think this is a roadblock, but something that would need to be made clear. I think each plugin should be individually compilable, so each plugin could be considered a separate entity. Sort of "amalgamation." But I'm not a license lawyer. > I would still prefer to keep plugins out of the opensync directory. > Actually i planned to do build testing by ctest and cdash. So i don't have to > build-test all plugins by myself. So far only few plugins get build-tested in > our cdash/ctest instance. Right now also some magic is required so they get > build tasted against latest trunk. I'm not a ctest / cdash expert, so I don't know how much easier this would make our lives, but the fact that there is no one maintainer who routinely builds all the plugins is a problem, in my opinion. Anyone who is changing the engine should be pro-actively looking for breakage in the plugins. The fact that the plugins are so far behind is due to this disconnect, in my opinion. If every change in the engine caused compile breakages in the plugins, those breakages would get fixed in the course of making the library changes. It would happen while the change was fresh in the engine developer's mind. It would be less bug prone, and better for users as well. I think it should be *optional* to build all the plugins, of course. But I also think it should be as easy as a cmake option to build all plugins, and the developer shouldn't have to go hunting for more SVN repos in order to do it. Building all plugins should be encouraged for any engine developer. > A SCM-repo with libopensync and all plugins > might would be a solution. Why not just checking out libopensync and all > plugins and write some special make target which jumps to the parent > directory or special directory where all plugins got checked out? I do have scripts to do this, somewhat, using git. It's extra work to make it happen, and I'd like to share that... the easiest way to share it seems to be in the opensync build process. > I guess only few developers going to need to build all plugins at the same > time. Those who plan to change/break the API. That shouldn't be the case so > often ... right? In theory. But like the linux kernel, the more compiler errors normal developers get, the faster things get fixed, I think. > But maybe we can provide all this to you some how without changing the entire > SCM? I can hack this up myself, and to some extent, I already have. But after all that work, it only improves my system. Everyone else has to do it themselves. :-) - Chris |
|
From: Daniel G. <go...@b1...> - 2010-08-14 00:47:40
|
On Saturday, August 14, 2010 09:09:50 am Chris Frey wrote: > ATTENTION anyone reading this thread: please let me know if this will cause > trouble that I don't foresee. I plan to update at least the opensync SVN > to get rid of its externals if possible, and put all plugins into it. I guess this would break our test automation we have running currently: http://opensync.org/testing/ And so far we only have one single svn:externals - and it's just for the cmake modules. Yeah, it's sad that this breaks git and others ... but the cmake- modules doesn't change that often. Actually we introduced that due to the fact that cmake and it's modules were still in a very early stage of development. So we had to write a couple of cmake modules by our own to find buliding depencies ... i guess some modules find their way already in recent cmake versions which already packaged in recent distribution. So we could think of getting replacing svn:externals by merging the changed modules - if required. How does that sounds to you? You might wanna try this for those repositories you're actively using - e.g. opensync, osynctool(?), google-calendar, file-sync, ... so you can use for those at least a git bridge. Regarding moving all plugins into one repo ... The Distribution packager might not be happy about that ... Since this would be heavy packaging change. Another problem might be the difference licenses. libopensync is LGPLv2 I guess most of the plugins are GPLvX or something else but in most cases not LGPLv ... something which packager might not like as well. I would still prefer to keep plugins out of the opensync directory. Actually i planned to do build testing by ctest and cdash. So i don't have to build-test all plugins by myself. So far only few plugins get build-tested in our cdash/ctest instance. Right now also some magic is required so they get build tasted against latest trunk. A SCM-repo with libopensync and all plugins might would be a solution. Why not just checking out libopensync and all plugins and write some special make target which jumps to the parent directory or special directory where all plugins got checked out? I guess only few developers going to need to build all plugins at the same time. Those who plan to change/break the API. That shouldn't be the case so often ... right? But maybe we can provide all this to you some how without changing the entire SCM? To sum this up: I'm ok with getting rid of cmake-modules svn:extenrals for some plugins and opensync and osynctool and use merge instead. And we should try to get as many of those merged to the cmake project. No SCM change before 0.40 got released. No plugins within opensync/trunk/ Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner Linux Consultant & Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Chris F. <cd...@fo...> - 2010-08-13 23:04:56
|
I've added a new API call: const char *osync_plugin_get_default_configdir(); This returns OPENSYNC_CONFIGDIR plus a G_DIR_SEPARATOR_S. I've also updated google-calendar to make use of this, to remove the need to specify a location for the .xslt files. - Chris On Thu, Jul 22, 2010 at 07:29:18PM -0400, Chris Frey wrote: > Hi, > > Is there a way to find the defaults directory (where the default config > starter files are stored) automatically inside the plugin? > > The google-calendar plugin has an advanced option in its config that > holds the path to where its .xslt files are. It would be nice to > be able to make this an optional specification, so the plugin could > find the default-installed .xslt files without the user needing > to know the directory hierarchy of libopensync. > > I notice that osync_member_get_config_or_default() uses OPENSYNC_CONFIGDIR, > but there's no API call to return this directory name that I can see. > > If this isn't possible with the current API, anybody have objections to > adding one? > > Thanks, > - Chris > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
90 messages has been excluded from this view by a project administrator.
