opensync-users — The place to get help for the OpenSync project

[Opensync-users] libsyncml: syncing with my googlemail contacts with syncml-ds-tool possible ?

[Olivier B. <ob...@ou...>]

Hi.

It seems to me, from the description in syncml-ds-tool's manpage, that
it should be possible to sync with Google mobile sync service to fetch
my contacts from the command-line. But I can't seem to understand how...

Here's an example :

 $ syncml-ds-tool --http-client https://m.google.com/syncml --slow-sync \
 text/x-vcard contacts --username xx...@go... --password \
 xxxxxxxx
 ** Message: ERROR: Command failed. The recipient encountered an
 unexpected condition which prevented it from fulfilling the
 request. Connection failed (400) - Bad Request

 $ olivier@asustour:~/syncml$ syncml-ds-tool --http-client \
 https://m.google.com/syncml --slow-sync text/x-vcard contacts \
 --username xx...@go... --password xxxxxxxx --wbxml
 ** Message: ERROR: Command failed. The recipient encountered an
 unexpected condition which prevented it from fulfilling the
 request. The alert response signals an error - 407.

Anyone with better ideas ? ... I may have missed the right docs, but it
seems there are not a lot of reports on attempting that when I'm
googleing for help.

Thanks in advance.

Best regards,
-- 
Olivier BERGER 
(OpenPGP: 1024D/B4C5F37F)
http://www.olivierberger.com/weblog/

Re: [Opensync-users] Ticket #1142 additional information

[Alexander T <mit...@gm...>]

Looks like my Nokia 5800 adds some junk after the UIDs although
stating QUOTED-PRINTABLE. Or could this be an effect of the post
processing?

So I have lines like
UID;ENCODING=QUOTED-PRINTABLE:12102009111752948625^R

I solved the problem by deleting the offending entries, but it would
be nice if one could figure out why this happens in the first place.

Best regards

Alexander T



On 8/26/10, Alexander T <mit...@gm...> wrote:
> Hi,
>
> I tried to comment on TRAC but I didn't have sufficient privileges and
> I couldn't find a signup link.
>
> I have the same problem, and performed the same test as suggested by
> settel. My output is:
>
> $ xmllint received-1.xml
> received-1.xml:851: parser error : CData section not finished
> BEGIN:VCALENDAR
> VERSION:1.0
> BEGIN:VEVENT
> UID;ENCOD
> UID;ENCODING=QUOTED-PRINTABLE:17092009115705350500
>                                                   ^
> received-1.xml:851: parser error : PCDATA invalid Char value 30
> UID;ENCODING=QUOTED-PRINTABLE:17092009115705350500
>                                                   ^
> received-1.xml:865: parser error : Sequence ']]>' not allowed in content
> END:VCALENDAR
>              ^
> received-1.xml:865: parser error : Sequence ']]>' not allowed in content
> ]]></Data></Item></Add><Add><CmdID>51</CmdID><Item><Source><LocURI>56</LocURI></
> ^
> received-1.xml:865: parser error : internal error
> ]]></Data></Item></Add><Add><CmdID>51</CmdID><Item><Source><LocURI>56</LocURI></
> ^
> received-1.xml:865: parser error : Extra content at the end of the document
> ]]></Data></Item></Add><Add><CmdID>51</CmdID><Item><Source><LocURI>56</LocURI></
> ^
>
> If you have an idea of how to fix it and just need some manpower
> please let me know and I will give it a try.
>
> Best Regards,
>
> Alexander T
>

[Opensync-users] Ticket #1142 additional information

[Alexander T <mit...@gm...>]

Hi,

I tried to comment on TRAC but I didn't have sufficient privileges and
I couldn't find a signup link.

I have the same problem, and performed the same test as suggested by
settel. My output is:

$ xmllint received-1.xml
received-1.xml:851: parser error : CData section not finished
BEGIN:VCALENDAR
VERSION:1.0
BEGIN:VEVENT
UID;ENCOD
UID;ENCODING=QUOTED-PRINTABLE:17092009115705350500
                                                  ^
received-1.xml:851: parser error : PCDATA invalid Char value 30
UID;ENCODING=QUOTED-PRINTABLE:17092009115705350500
                                                  ^
received-1.xml:865: parser error : Sequence ']]>' not allowed in content
END:VCALENDAR
             ^
received-1.xml:865: parser error : Sequence ']]>' not allowed in content
]]></Data></Item></Add><Add><CmdID>51</CmdID><Item><Source><LocURI>56</LocURI></
^
received-1.xml:865: parser error : internal error
]]></Data></Item></Add><Add><CmdID>51</CmdID><Item><Source><LocURI>56</LocURI></
^
received-1.xml:865: parser error : Extra content at the end of the document
]]></Data></Item></Add><Add><CmdID>51</CmdID><Item><Source><LocURI>56</LocURI></
^

If you have an idea of how to fix it and just need some manpower
please let me know and I will give it a try.

Best Regards,

Alexander T

Re: [Opensync-users] testing and documenting 0.4X

[Emanoil K. <del...@ya...>]

--- On Tue, 8/24/10, Chris Frey <cd...@fo...> wrote:


> 
> 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. :-)
> 

Thanks for the info. I've almost completed the update on the server. I think next week I'll be able to download and start compiling/working. (hopefully nothing will come in between)

regards


      

Re: [Opensync-users] testing and documenting 0.4X

[Chris F. <cd...@fo...>]

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

Re: [Opensync-users] testing and documenting 0.4X

[Emanoil K. <del...@ya...>]

Thanks for the details

--- On Fri, 8/20/10, Chris Frey <cd...@fo...> 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.

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

> 
> 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.

yes sure. I have a non syncml and a syncml nokia at home. The syncml is also kind of working with the current 0.2x engine and kde 3.5 (over bluetooth), but it still breaks and can only sync contacts - nothing else. So I would be glad if the opensync syncml part is working well.

regards


      

Re: [Opensync-users] testing and documenting 0.4X

[Graham C. <g+o...@co...>]

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

Re: [Opensync-users] testing and documenting 0.4X

[Chris F. <cd...@fo...>]

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

[Opensync-users] New logo

[Quentin D. <que...@gm...>]

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

Re: [Opensync-users] testing and documenting 0.4X

[Emanoil K. <del...@ya...>]

Thanks for the good word.

--- On Wed, 8/18/10, Quentin Denis <que...@gm...> wrote:

> 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.

yes. I think there is big interest in the community to get it done.

> 
> 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! ;)

svn co http://websvn.kde.org/trunk/KDE/kdepim/runtime/opensync
svn: Repository moved permanently to '/trunk/KDE/kdepim/runtime/opensync/'; please relocate

So could you give me a hint how to get the code in an easy way?

> 
> 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

Had a look sounds clear, I'll check if useful. I need to get the code and get an impression in what needs to be done.

> 
> 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.

Actually I'm still using kde 3.5 but I'm in the process of testing kde 4.4 and migrating custom software that I'm using for business. The deadline is by the end of September to get a working env on the desktop/notebook. and maybe in few weeks I'll have a server with kde4.4. So probably in 2 weeks I'll be ready to start. Until then evaluating.

http://pim.kde.org/akonadi seem to be a good starting point

> 
> 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.

Thanks I'll have look around, set up an environment and come to you later.

Your current e-mail was very helpful as I need guidance where to start. May be akonadi is a good point and task.

regards


      

Re: [Opensync-users] testing and documenting 0.4X

[Quentin D. <que...@gm...>]

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

[Opensync-users] testing and documenting 0.4X

[Emanoil K. <del...@ya...>]

--- 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



      

Re: [Opensync-users] Fwd: Google plugin for opensync

[Chris F. <cd...@fo...>]

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

Re: [Opensync-users] Fwd: Google plugin for opensync

[Quentin D. <que...@gm...>]

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!

Re: [Opensync-users] What to look for in a cell phone

[Ernest S. <er...@gm...>]

On Tue, 10 Aug 2010 17:50:56 -0500, Jon Schewe wrote:
>  On 8/10/10 3:45 PM, Chris Frey wrote:
> > On Sun, Aug 08, 2010 at 08:09:00AM -0500, Jon Schewe wrote:
> >>  I'm looking at getting a basic cell phone that I can sync 
> the contacts
> >> with Linux. I do not want a smartphone for a variety of 
> reasons (I can
> >> have a separate discussion about that if you'd like). My 
> understanding
> >> is that opensync is the only real way to do this under 
> Linux, is this
> >> correct? What things should I look for in a cell phone that will
> >> increase the probability that opensync will work with it? My cell
> >> carrier is Verizon.
> > Hopefully others will chime in with their thoughts, but it 
> is my understanding
> > that syncML is the "wave of the future" when it comes to 
> syncing, so that
> > might be a good feature to look for.
> Is this something that can be found in many basic phones (ie. not
> smartphones) that only have bluetooth and USB for connections?

SyncML is not yet mainstream in basic phones, but there are several models
available, depending on your region. For instance:
* USA: Nokia 2730 $99, Motorola E8 $120
* EU: Nokia 2720 fold ?65, Samsung E2100 ?33
These are just some examples found in a quick search; never tried them. I
guess there are a lot more, just look deep in the specifications: this is
not an emphasized feature.

Ernest

Re: [Opensync-users] SCM changes? (was: Re: [Opensync-devel] Fwd: Google plugin for opensync)

[Chris F. <cd...@fo...>]

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

[Opensync-users] SCM changes? (was: Re: [Opensync-devel] Fwd: Google plugin for opensync)

[Daniel G. <go...@b1...>]

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

Re: [Opensync-users] Fwd: Google plugin for opensync

[Chris F. <cd...@fo...>]

On Fri, Aug 13, 2010 at 10:32:56AM +0200, Quentin Denis wrote:
> I think it is high time to finally
> release a stable 0.40 version, including up-to-date plugins (the engine
> without plugins makes the project useless).

Hi Quentin,

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.


> So, my recommendation is to concentrate all the efforts on a new stable
> release with all plugins working before these two projects dethrone you. The
> next urgent thing would be then to create an Akonadi plugin [1] and the
> opensync suite is back on the desktop!
> Try to create a buzz around the new and finally stable release. Publish beta
> versions and release candidates. Announce news on the website; show that you
> are still actively developing it. ... And I will update the wiki, I promise!

I see you've already updated the wiki... nice!  Thanks!


> Concerning the google plugin, Adenilson told me about the current features
> of libgcal:
> 
> "Later in 2008, I asked his permission to continue this work, and started by
> first writing a C library for google data protocol (libgcal) implementing
> both calendar and contacts. And at the same year I re-wrote the opensync
> gcalendar plugin and wrote  a new contacts plugin.
> 
> In 2009, I started akonadi resources using libgcal. You can read more about
> both in here:
> http://savago.wordpress.com/2010/06/11/libgcal-0-9-4-released/
> http://savago.wordpress.com/2010/06/20/libgcal-0-9-5-plus-a-video/
> "

You also mentioned "tasks" in your earlier email... I can see libgcal API
for contacts and calendar, but not sure about tasks.

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.

- Chris

Re: [Opensync-users] Fwd: Google plugin for opensync

[Quentin D. <que...@gm...>]

Hi Chris,

thank you very much for your long response and the clearing up of the
situation. I am happy to know that there is still a motivated and very
active developer in the opensync team. I think it is high time to finally
release a stable 0.40 version, including up-to-date plugins (the engine
without plugins makes the project useless). I have recently been in contact
with former opensync contributors or potential contributors, there all told
me that they stopped working on opensync because of its constant API changes
and lack of progress and stability.

I my opinion, it is urgent to bring opensync back on track. Many users and
developers are disappointed of the stalled progress and moved towards other
solutions. Some innovative projects will some make opensync a dead and
outdated application, two projects in particular are about to bring the
ultimate solution for KDE users:
- http://saidinesh5.wordpress.com/
<http://saidinesh5.wordpress.com/>- https://akunambol.forge.funambol.org/
So, my recommendation is to concentrate all the efforts on a new stable
release with all plugins working before these two projects dethrone you. The
next urgent thing would be then to create an Akonadi plugin [1] and the
opensync suite is back on the desktop!
Try to create a buzz around the new and finally stable release. Publish beta
versions and release candidates. Announce news on the website; show that you
are still actively developing it. ... And I will update the wiki, I promise!

Concerning the google plugin, Adenilson told me about the current features
of libgcal:

"Later in 2008, I asked his permission to continue this work, and started by
first writing a C library for google data protocol (libgcal) implementing
both calendar and contacts. And at the same year I re-wrote the opensync
gcalendar plugin and wrote  a new contacts plugin.

In 2009, I started akonadi resources using libgcal. You can read more about
both in here:
http://savago.wordpress.com/2010/06/11/libgcal-0-9-4-released/
http://savago.wordpress.com/2010/06/20/libgcal-0-9-5-plus-a-video/
"

So, I don't know what is really implemented in the opensync plugin; but
libgcal provides all these features. According to Adenilson, he has already
given up altogether of maintaining the opensync plugins and decided to
maintain the akonadi resources (which can be used with Kontact and
Kaddressbook).

Ok, so far so good, I hope things will evolve the best as opensync deserves.

Best regards and nice work,
Quentin Denis
<http://savago.wordpress.com/2010/06/20/libgcal-0-9-5-plus-a-video/>

[1] Some work has been done on it quite a while ago; but it seems to have
been removed from svn:
http://websvn.kde.org/trunk/playground/pim/
There you will also find discontinued projects like kitchensync
(discontinued because of the constant API changes, too).


On Thu, Aug 12, 2010 at 7:44 PM, Chris Frey <cd...@fo...> wrote:

> Hi Quentin,
>
> Thanks for your message... I'll reply to the list, in case others wish
> to join in.
>
> I guess you could say that I'm the latest in a line of maintainers
> for the google-calendar plugin.  I'm interested in getting opensync
> 0.39 working for personal reasons.  I'd like to see opensync continue,
> and I think 0.4x is so close to being useful that it would be a shame
> to drop it now.
>
> The primary issue is lack of ported plugins, and I'm working on that
> slowly.
>
> I think I might be the only developer committing code at the moment,
> though.
> And slowly at that!  But the 0.39 engine is useable, and arguably better
> than 0.22.  If the plugins were up to date, I think we could release it,
> and get more interest from users and maybe developers.
>
> I haven't followed Akonadi too closely.  Does it have the same range of
> syncing abilities that opensync 0.22 has?
>
> As for adding tasks support to the Google plugin, that would require
> support to be added in libgcal, and I don't think it's there yet?
> If libgcal had that support, I'd be interested in updating the plugin
> to support it.
>
> Adenilson, does libgcal support tasks and I just don't see it?
>
> - Chris
>
>
>
> On Thu, Aug 12, 2010 at 10:28:31AM +0200, Quentin Denis wrote:
> > Hello,
> >
> > I have sent this message to the authors of the google-calendar plugin, it
> > might interest you, too. I would be especially interested in getting
> status
> > update of the Akonadi plugin; this would bring back a lot of KDE users
> and
> > make opensync revive.
> >
> > Best regards,
> > Quentin Denis
> >
> >
> > ---------- Forwarded message ----------
> > From: Quentin Denis <que...@gm...>
> > Date: Thu, Aug 12, 2010 at 10:00 AM
> > Subject: Google plugin for opensync
> > To: ade...@in..., cd...@fo...,
> eha...@ra...
> >
> >
> > Hello guys,
> >
> > thanks to you, opensync has a powerful google calendar plugin. Lately,
> > Google has improved it's features and now offers "Tasks" and improved
> > "Contact". It would be nice to sync both with my Gnokii "Notes" and
> > "Addressbook", so are you interested in extending the existing plugin to
> > include these new features? It would bring a lot of users back to
> opensync
> > since this is a very useful synchronisation element. Opensync is too
> > restricted to Gnome users (evolution, tomboy, ...) and a complete Google
> > plugin would enable other users to escape this lack of plugins (KDE4
> plugin
> > being as dead as it has never been...).
> >
> > By the way, could enlighten me about the actual development status of
> > opensync? Is it still very active or is it moving to a dead end? Are all
> the
> > plugins compatible with the latest opensync api? What about Akonadi
> support?
> >
> > Thanks a lot for your work and looking forward to enjoying a more
> complete
> > Google plugin,
> > kind regards,
> > Quentin Denis
>
> >
> ------------------------------------------------------------------------------
> > 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
>
>

Re: [Opensync-users] Fwd: Google plugin for opensync

[Chris F. <cd...@fo...>]

Hi Quentin,

Thanks for your message... I'll reply to the list, in case others wish
to join in.

I guess you could say that I'm the latest in a line of maintainers
for the google-calendar plugin.  I'm interested in getting opensync
0.39 working for personal reasons.  I'd like to see opensync continue,
and I think 0.4x is so close to being useful that it would be a shame
to drop it now.

The primary issue is lack of ported plugins, and I'm working on that
slowly.

I think I might be the only developer committing code at the moment, though.
And slowly at that!  But the 0.39 engine is useable, and arguably better
than 0.22.  If the plugins were up to date, I think we could release it,
and get more interest from users and maybe developers.

I haven't followed Akonadi too closely.  Does it have the same range of
syncing abilities that opensync 0.22 has?

As for adding tasks support to the Google plugin, that would require
support to be added in libgcal, and I don't think it's there yet?
If libgcal had that support, I'd be interested in updating the plugin
to support it.

Adenilson, does libgcal support tasks and I just don't see it?

- Chris



On Thu, Aug 12, 2010 at 10:28:31AM +0200, Quentin Denis wrote:
> Hello,
> 
> I have sent this message to the authors of the google-calendar plugin, it
> might interest you, too. I would be especially interested in getting status
> update of the Akonadi plugin; this would bring back a lot of KDE users and
> make opensync revive.
> 
> Best regards,
> Quentin Denis
> 
> 
> ---------- Forwarded message ----------
> From: Quentin Denis <que...@gm...>
> Date: Thu, Aug 12, 2010 at 10:00 AM
> Subject: Google plugin for opensync
> To: ade...@in..., cd...@fo..., eha...@ra...
> 
> 
> Hello guys,
> 
> thanks to you, opensync has a powerful google calendar plugin. Lately,
> Google has improved it's features and now offers "Tasks" and improved
> "Contact". It would be nice to sync both with my Gnokii "Notes" and
> "Addressbook", so are you interested in extending the existing plugin to
> include these new features? It would bring a lot of users back to opensync
> since this is a very useful synchronisation element. Opensync is too
> restricted to Gnome users (evolution, tomboy, ...) and a complete Google
> plugin would enable other users to escape this lack of plugins (KDE4 plugin
> being as dead as it has never been...).
> 
> By the way, could enlighten me about the actual development status of
> opensync? Is it still very active or is it moving to a dead end? Are all the
> plugins compatible with the latest opensync api? What about Akonadi support?
> 
> Thanks a lot for your work and looking forward to enjoying a more complete
> Google plugin,
> kind regards,
> Quentin Denis

> ------------------------------------------------------------------------------
> 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

Re: [Opensync-users] What to look for in a cell phone

[Chris F. <cd...@fo...>]

On Tue, Aug 10, 2010 at 05:50:56PM -0500, Jon Schewe wrote:
>  On 8/10/10 3:45 PM, Chris Frey wrote:
> > that syncML is the "wave of the future" when it comes to syncing, so that
> > might be a good feature to look for.
> Is this something that can be found in many basic phones (ie. not
> smartphones) that only have bluetooth and USB for connections?

That, I'm afraid, I don't know.  I don't keep up with the latest phone
developments too well.

- Chris

[Opensync-users] Fwd: Google plugin for opensync

[Quentin D. <que...@gm...>]

Hello,

I have sent this message to the authors of the google-calendar plugin, it
might interest you, too. I would be especially interested in getting status
update of the Akonadi plugin; this would bring back a lot of KDE users and
make opensync revive.

Best regards,
Quentin Denis


---------- Forwarded message ----------
From: Quentin Denis <que...@gm...>
Date: Thu, Aug 12, 2010 at 10:00 AM
Subject: Google plugin for opensync
To: ade...@in..., cd...@fo..., eha...@ra...


Hello guys,

thanks to you, opensync has a powerful google calendar plugin. Lately,
Google has improved it's features and now offers "Tasks" and improved
"Contact". It would be nice to sync both with my Gnokii "Notes" and
"Addressbook", so are you interested in extending the existing plugin to
include these new features? It would bring a lot of users back to opensync
since this is a very useful synchronisation element. Opensync is too
restricted to Gnome users (evolution, tomboy, ...) and a complete Google
plugin would enable other users to escape this lack of plugins (KDE4 plugin
being as dead as it has never been...).

By the way, could enlighten me about the actual development status of
opensync? Is it still very active or is it moving to a dead end? Are all the
plugins compatible with the latest opensync api? What about Akonadi support?

Thanks a lot for your work and looking forward to enjoying a more complete
Google plugin,
kind regards,
Quentin Denis

Re: [Opensync-users] What to look for in a cell phone

[Jon S. <jps...@mt...>]

 On 8/10/10 3:45 PM, Chris Frey wrote:
> On Sun, Aug 08, 2010 at 08:09:00AM -0500, Jon Schewe wrote:
>>  I'm looking at getting a basic cell phone that I can sync the contacts
>> with Linux. I do not want a smartphone for a variety of reasons (I can
>> have a separate discussion about that if you'd like). My understanding
>> is that opensync is the only real way to do this under Linux, is this
>> correct? What things should I look for in a cell phone that will
>> increase the probability that opensync will work with it? My cell
>> carrier is Verizon.
> Hopefully others will chime in with their thoughts, but it is my understanding
> that syncML is the "wave of the future" when it comes to syncing, so that
> might be a good feature to look for.
Is this something that can be found in many basic phones (ie. not
smartphones) that only have bluetooth and USB for connections?

-- 
Jon Schewe | http://mtu.net/~jpschewe
If you see an attachment named signature.asc, this is my digital
signature. See http://www.gnupg.org for more information.

Re: [Opensync-users] What to look for in a cell phone

[Chris F. <cd...@fo...>]

On Sun, Aug 08, 2010 at 08:09:00AM -0500, Jon Schewe wrote:
>  I'm looking at getting a basic cell phone that I can sync the contacts
> with Linux. I do not want a smartphone for a variety of reasons (I can
> have a separate discussion about that if you'd like). My understanding
> is that opensync is the only real way to do this under Linux, is this
> correct? What things should I look for in a cell phone that will
> increase the probability that opensync will work with it? My cell
> carrier is Verizon.

Hopefully others will chime in with their thoughts, but it is my understanding
that syncML is the "wave of the future" when it comes to syncing, so that
might be a good feature to look for.

- Chris

Re: [Opensync-users] trac spammed

[Chris F. <cd...@fo...>]

On Tue, Aug 10, 2010 at 01:36:25PM -0300, Fernando Toledo wrote:
> http://www.opensync.org/timeline
> hi people, 
> i can help to configure the trac update it and put some spam filters.
> but
> i want to contact to the trac maintainer.
> i see this project very inactive and i like it 
> is the developers thinking in some roadmap?


Hi Fernando,

Thanks for the notice.  I don't think I have the access to fix that,
but I've CC'd Daniel, and I'm sure he'll take a look.

The project is somewhat slow these days.  Mostly due to free time for
developers.  I'm currently working on getting the google-calendar plugin
updated to the latest API, and fixing any bugs I find in it.  There are
other plugins that need work as well, in case there are developers who
wish to tackle them.

- Chris