opensync-devel — The place to coordinate the development of OpenSync

Re: [Opensync-devel] New logo

[griffin <gr...@ub...>]

uploaded several other variations, including font & color, as well as one
version without the outer background fade, making it (i think) look
less "busy".

On Sun, 05 Sep 2010 14:12:47 -0400, Chris Frey <cd...@fo...>  
wrote:

> Strangely, between the two, I like the original pastel one best. :-)
> The thinner letters look more professional to me.
>
> - Chris
>
>
> On Sun, Sep 05, 2010 at 01:00:43PM -0400, griffin wrote:
>> made a new version of the pastel logo with
>>    - added arrows
>>    - improved conical fade
>>    - pure SVG implementation
>>
>> let me know what you think.
>>
>> On Tue, 24 Aug 2010 13:27:03 -0400, griffin <gr...@ub...> wrote:
>>
>> > 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.
>> >
>> >  
>> ------------------------------------------------------------------------------
>> > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> > Be part of this innovative community and reach millions of netbook  
>> users
>> > worldwide. Take advantage of special opportunities to increase revenue
>> > and
>> > speed time-to-market. Join now, and jumpstart your future.
>> > http://p.sf.net/sfu/intel-atom-d2d
>> > _______________________________________________
>> > Opensync-devel mailing list
>> > Ope...@li...
>> > https://lists.sourceforge.net/lists/listinfo/opensync-devel
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Opensync-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] New logo

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

Strangely, between the two, I like the original pastel one best. :-)
The thinner letters look more professional to me.

- Chris


On Sun, Sep 05, 2010 at 01:00:43PM -0400, griffin wrote:
> made a new version of the pastel logo with
>    - added arrows
>    - improved conical fade
>    - pure SVG implementation
> 
> let me know what you think.
> 
> On Tue, 24 Aug 2010 13:27:03 -0400, griffin <gr...@ub...> wrote:
> 
> > 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.
> >
> > ------------------------------------------------------------------------------
> > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> > Be part of this innovative community and reach millions of netbook users
> > worldwide. Take advantage of special opportunities to increase revenue  
> > and
> > speed time-to-market. Join now, and jumpstart your future.
> > http://p.sf.net/sfu/intel-atom-d2d
> > _______________________________________________
> > Opensync-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensync-devel
> 
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
> 
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] binary package build scripts

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

On Sun, Sep 05, 2010 at 01:27:40PM +0300, Juha Tuomala wrote:
> I'm for example maintaining pkgs for Fedora and even run Koji build
> system of my own. Lack of packages is not a problem.

Cool!  Are your spec files, etc, available in SVN somewhere in case
I wish to follow them personally?  If packages are already available,
I don't want to duplicate effort, but when opensync is completely
gone from Debian Squeeze (both 0.22 and 0.3x), it has me worried,
and someone should stay on top of it.


> Our problem was that there were packages in Fedora which were from 
> 0.2x branch and everyone was reporting bugs/focusing on those. I
> even tried hard to get them to drop those without luck.
> 
> Then we had problem that development broke too many things that
> SCM HEAD was unusable and didn't really make sense to ship even
> for testing.

I remember when Fedora went to 0.3x.  And the API breakage was expected.
I don't think any 0.3x version should be in an official distro, unless
0.22 is there beside it.

But I *do* think that binary packages for 0.3x should be available
somewhere, for those that wish to test.  There are some 0.3x in
Debian experimental... I assume you have some for Fedora?
Not sure about openSuSE.


> The question is, has that change recently? I tried to ask
> this from core developer, but never got any reply.
> 
> There is plenty of people waiting to join back to the minor tasks
> for opensync if there actually would be something to do.

That's great to hear.  Are there any programmers in that set, or are
we talking about packaging tasks?

Are their packages for the 0.3x plugins yet?

As soon as a significant number of plugins are ported over, I think
we should release 0.4x.  So far, the status is:

	Evolution: done
	Barry: done
	File-sync: done
	Ldap: I think done, but I need to give it a test run
	Google-calendar: 50% done, only calendar

Anyone with a syncml phone willing to test the syncml stuff and report
whether it's done or not?

Thanks,
- Chris

Re: [Opensync-devel] binary package build scripts

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

On Sun, Sep 05, 2010 at 04:59:42PM +0200, Michael Banck wrote:
> There is a subversion repository for the 0.3x Debian packages.

Cool.  Can you point me in the right direction?

Thanks,
- Chris

Re: [Opensync-devel] New logo

[griffin <gr...@ub...>]

made a new version of the pastel logo with
   - added arrows
   - improved conical fade
   - pure SVG implementation

let me know what you think.

On Tue, 24 Aug 2010 13:27:03 -0400, griffin <gr...@ub...> wrote:

> 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.
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue  
> and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] binary package build scripts

[Michael B. <mb...@gm...>]

On Sat, Sep 04, 2010 at 06:35:00PM -0400, Chris Frey wrote:
> On Sat, Sep 04, 2010 at 02:10:26PM +0300, Juha Tuomala wrote:
> > 
> > On Saturday 04 September 2010 04:37:48 Chris Frey wrote:
> > > Where do I find the binary package build scripts for opensync and all
> > > the plugins?  I'm looking for both deb and rpm.
> > 
> > Let's hope they don't exist and that remains so.
> > 
> > It's not the upstream's job to make those, it will 
> > fail anyway if attempted.
> 
> It is upstream's job if the packages do not exist in the distros yet,
> or anymore.
> 
> I can grab the scripts from the source packages, but I was hoping there
> was some SVN or git repo where I can actually help the packagers if I find
> bugs.

There is a subversion repository for the 0.3x Debian packages.  For the
0.2x packages, no repository exists.  Not sure which packages you were
talking about anyway, though.


Michael

Re: [Opensync-devel] binary package build scripts

[Juha T. <Juh...@ik...>]

On Sat, 4 Sep 2010, Chris Frey wrote:
>> Let's hope they don't exist and that remains so.
>>
>> It's not the upstream's job to make those, it will
>> fail anyway if attempted.
>
> It is upstream's job if the packages do not exist in the distros yet,
> or anymore.

I'm for example maintaining pkgs for Fedora and even run Koji build
system of my own. Lack of packages is not a problem.

Our problem was that there were packages in Fedora which were from 
0.2x branch and everyone was reporting bugs/focusing on those. I
even tried hard to get them to drop those without luck.

Then we had problem that development broke too many things that
SCM HEAD was unusable and didn't really make sense to ship even
for testing.

The question is, has that change recently? I tried to ask
this from core developer, but never got any reply.

There is plenty of people waiting to join back to the minor tasks
for opensync if there actually would be something to do.


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.

Re: [Opensync-devel] binary package build scripts

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

On Sat, Sep 04, 2010 at 02:10:26PM +0300, Juha Tuomala wrote:
> 
> On Saturday 04 September 2010 04:37:48 Chris Frey wrote:
> > Where do I find the binary package build scripts for opensync and all
> > the plugins?  I'm looking for both deb and rpm.
> 
> Let's hope they don't exist and that remains so.
> 
> It's not the upstream's job to make those, it will 
> fail anyway if attempted.

It is upstream's job if the packages do not exist in the distros yet,
or anymore.

I can grab the scripts from the source packages, but I was hoping there
was some SVN or git repo where I can actually help the packagers if I find
bugs.

- Chris

Re: [Opensync-devel] binary package build scripts

[Juha T. <Juh...@ik...>]

On Saturday 04 September 2010 04:37:48 Chris Frey wrote:
> Where do I find the binary package build scripts for opensync and all
> the plugins?  I'm looking for both deb and rpm.

Let's hope they don't exist and that remains so.

It's not the upstream's job to make those, it will 
fail anyway if attempted.


Tuju

-- 
Better to have one, and not need it, than to need one and not have it.

[Opensync-devel] binary package build scripts

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

Hi,

Where do I find the binary package build scripts for opensync and all
the plugins?  I'm looking for both deb and rpm.

Thanks,
- Chris

Re: [Opensync-devel] google-calendar plugin working for calendar only

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

Hi folks,

Another update on the google-calendar plugin front.  Calendar syncing
now works for me, except for recurring events.  I haven't looked much
at that yet... I was struggling with Google so far.

I have some confidence that this will work for others as well, so if you
feel like an early adopter, download the latest opensync, vformat,
xmlformat, and google-calendar plugins, and give them a go.

You will need to use the latest git tree of libgcal.  You can grab my
tree at git://repo.or.cz/libgcal/libgcal-cdf.git  (use the cdfrey branch)
or you can grab the official one at gitorious.

What does not work:
	contacts
	recurring events

Please let me know if you find any problems in your testing!

- Chris

[Opensync-devel] [PATCH] API and compile changes to match latest opensync library

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

---

Just a quick patch to get the xsltformat plugin to compile
against latest opensync.

- Chris



 src/xsltformat.c |   33 +++++++++++++++++++++------------
 1 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/src/xsltformat.c b/src/xsltformat.c
index b851b17..2b99e2d 100644
--- a/src/xsltformat.c
+++ b/src/xsltformat.c
@@ -45,7 +45,7 @@ static osync_bool conv_xslt_to_contact(char *input, unsigned int inpsize, char *
 	if ((result = xslt_transform(converter, input)))
 		goto exit;
 
-	if (!(*output = strdup(converter->xml_str)))
+	if (!(*output = strdup((char*)converter->xml_str)))
 		goto exit;
 
 	*free_input = TRUE;
@@ -68,7 +68,7 @@ static osync_bool conv_contact_to_xslt(char *input, unsigned int inpsize, char *
 	if ((result = xslt_transform(converter, input)))
 		goto exit;
 
-	if (!(*output = strdup(converter->xml_str)))
+	if (!(*output = strdup((char*)converter->xml_str)))
 		goto exit;
 
 	*free_input = TRUE;
@@ -83,13 +83,14 @@ exit:
 }
 
 
+/*
 static void destroy_format1(char *input, unsigned int inpsize, void *user_data)
 {
-	/*
-	 * Here you have to free the data allocated by your format
-	 *
-	 */
+	//
+	// Here you have to free the data allocated by your format
+	//
 }
+*/
 
 osync_bool get_format_info(OSyncFormatEnv *env, OSyncError **error)
 {
@@ -97,7 +98,8 @@ osync_bool get_format_info(OSyncFormatEnv *env, OSyncError **error)
 	if (!format)
 		return FALSE;
 
-	osync_format_env_register_objformat(env, format);
+	if( !osync_format_env_register_objformat(env, format, error) )
+		return FALSE;
 	osync_objformat_unref(format);
 
 	return TRUE;
@@ -118,15 +120,15 @@ void *initialize_xslt(const char* config, OSyncError **error)
 
 }
 
-void finalize_xslt(void *userdata)
+static osync_bool finalize_xslt(void *userdata, OSyncError **error)
 {
 	struct xslt_resources *converter = NULL;
 	if (!userdata)
-		return;
+		return FALSE;
 
 	converter = (struct xslt_resources *)userdata;
 	xslt_delete(converter);
-
+	return TRUE;
 }
 
 static osync_bool reg_conv(OSyncFormatEnv *env,
@@ -140,15 +142,22 @@ static osync_bool reg_conv(OSyncFormatEnv *env,
 							 from, to,
 							 convert_func, &error);
 	if (!conv)
-		return FALSE;
+		goto error;
 
 	osync_converter_set_initialize_func(conv, initialize_func);
 	osync_converter_set_finalize_func(conv, finalize_func);
-	osync_format_env_register_converter(env, conv);
+	if( !osync_format_env_register_converter(env, conv, &error) )
+		goto error;
 	osync_converter_unref(conv);
 
 	return TRUE;
 
+error:
+	if( conv )
+		osync_converter_unref(conv);
+	osync_trace(TRACE_INTERNAL, "%s", osync_error_print(&error));
+	osync_error_unref(&error);
+	return FALSE;
 }
 
 osync_bool get_conversion_info(OSyncFormatEnv *env, OSyncError **error)
-- 
1.7.0.3

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

On Mon, Aug 30, 2010 at 01:22:01PM -0400, Adenilson Cavalcanti wrote:
> > The event type seemed to me to be an opaque type. ?i.e. I'm not supposed
> > to access the internals directly, right? ?So if all I have is the
> > edit_url, how should I delete with gcal_erase_event(gcal_t, gcal_event_t)?
> > Perhaps I'm supposed to call set_url() first?
> 
> Exactly, you should set the edit url in the gcal_event_t 'object'.

Thanks.  That should work.


> The changed method is something that I can't accept, because it will
> break with ABI. I used the concept of 'objects' in libgcal to hide
> implementation details from users and ensure that all memory allocated
> by the library would be freed by it.

I'm going to get slightly argumentative here, but I mean no harm.
And I don't mind if you don't apply the patch either, even for a trvial
reason that you just don't like it. :-)

But I don't believe that gcal_delete_event_url() will break the ABI.  (I think
"ABI" might be a C++ concept anyway, which doesn't affect libgcal.)
The patch only adds a function, does not remove any, nor does it change
any existing function prototypes.

I don't see how gcal_delete_event_url() would in any way cause leaked memory,
either.


As a side note, before you release a nice shiny version 1.0 of libgcal,
somebody should fix all the const-correctness issues in the API. :-)
It's already bit me in the opensync plugin once.  I can work up a patch
if you like.

Thanks for the feedback!
- Chris

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

[Adenilson C. <cav...@gm...>]

Chris

I will answer inline.

> Ok, here's the background on why I added that.  It might be my lack of
> knowledge about the API that made me think I needed it.
>
> In the google-calendar plugin, I'm storing all three items for every
> entry: the ID, the edit_url, and the etag.  Using the edit_url and the
> etag together was the only way I could get it to work.  Everything else
> I tried just ended in frustration.

Just the edit_url should be enough.


> The event type seemed to me to be an opaque type.  i.e. I'm not supposed
> to access the internals directly, right?  So if all I have is the
> edit_url, how should I delete with gcal_erase_event(gcal_t, gcal_event_t)?
> Perhaps I'm supposed to call set_url() first?
>

Exactly, you should set the edit url in the gcal_event_t 'object'.


> This says I have to retrieve the old one first, and then delete it.
> Is this required?
>

This means that once you have downloaded the event, if this event has
not changed on the google server, you only need the edit_url to delete
it.

If something has changed in the server side, then you need to query
for updates and use the new edit_url.


The changed method is something that I can't accept, because it will
break with ABI. I used the concept of 'objects' in libgcal to hide
implementation details from users and ensure that all memory allocated
by the library would be freed by it.

I've inspected your patches and merged them into libgcal main
repository, it will be part of the 0.9.6 release (it has not any new
feature, only bug-fixes).

I hope that this fixes the opensync case (and hopefully pretty soon
the distributions will start to use this new version).


Best regards


Adenilson

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

On Sun, Aug 29, 2010 at 12:12:29PM -0400, Adenilson Cavalcanti wrote:
> Chris
> 
> I've checked the patches, and I got to say that I liked it (you even
> remembered adding the examples from libgcal website, this is something
> I was supposed to do ages ago...).
> :-)

Thanks!


> I'm just not sure about this one:
> http://repo.or.cz/w/libgcal/libgcal-cdf.git/blobdiff/6f74f867f1af0ddafa8bc96a63d3a664c09f5605..b8096cbef66527a0ec778dbf40cc47b5af202501:/src/gcal.c
> 
> Why add a new function to delete an event if gcalendar.h already has it?
> 332 int gcal_erase_event(gcal_t gcal_obj, gcal_event_t event)?

Ok, here's the background on why I added that.  It might be my lack of
knowledge about the API that made me think I needed it.

In the google-calendar plugin, I'm storing all three items for every
entry: the ID, the edit_url, and the etag.  Using the edit_url and the
etag together was the only way I could get it to work.  Everything else
I tried just ended in frustration.

When I'm ready to delete an entry, all I have is the edit_url.  When
reading libgcal's source code, it seemed that the library just copied
the edit_url from the gcal_event_t to do the delete.  In fact, in one
function, it actually created an empty type, filled in the edit_url, and
then called delete.

The event type seemed to me to be an opaque type.  i.e. I'm not supposed
to access the internals directly, right?  So if all I have is the
edit_url, how should I delete with gcal_erase_event(gcal_t, gcal_event_t)?
Perhaps I'm supposed to call set_url() first?

Anyway, that was my problem, and why I added the new API.  It seemed
like the library went to great lengths to copy the edit_url around, when
passing it in as an argument was all that was needed.


> http://code.google.com/apis/calendar/data/2.0/developers_guide_protocol.html#DeletingEvents

This says I have to retrieve the old one first, and then delete it.
Is this required?


> So, after we worked this minor issue, your patches are clean to go
> into libgcal mainstream. Again, if you can, I suggest to base yourself
> using the gitorious repository, since it has a better and cleaner
> interface for me to handle merge requests.

If you add my repo.or.cz url as a remote in your own repository, you can
handle merge and diffs straight from the command line.

I don't like gitorious, since it depends on javascript too much.  I couldn't
even find the git pull URL without javascript, which is kinda sad. :-)

But I've added the gitorious repo as a remote for me, so I can base all
my work on your latest code.  That's the nice thing about git... it doesn't
matter where people host their repos.

Thanks,
- Chris

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

[Adenilson C. <cav...@gm...>]

Chris

I've checked the patches, and I got to say that I liked it (you even
remembered adding the examples from libgcal website, this is something
I was supposed to do ages ago...).
:-)

I'm just not sure about this one:
http://repo.or.cz/w/libgcal/libgcal-cdf.git/blobdiff/6f74f867f1af0ddafa8bc96a63d3a664c09f5605..b8096cbef66527a0ec778dbf40cc47b5af202501:/src/gcal.c

Why add a new function to delete an event if gcalendar.h already has it?
332 int gcal_erase_event(gcal_t gcal_obj, gcal_event_t event)?


The organization in libgcal is:
a) gcal.h has the dirty and tricky parts of doing the stuff
b) gcalendar.h has the 'public' API, hiding some complexities.

Finally, it seems to be a misunderstanding: IIRC, the edit url is the
same used to do edit and delete operations, the difference is that you
will use a HTTP PUT for edit and HTTP DELETE to erase an entry
(without the need to add the payload entry in the request). I assume
that you are already familiar with this, right? I suggest you to read
this:
http://code.google.com/apis/calendar/data/2.0/developers_guide_protocol.html#DeletingEvents

So, after we worked this minor issue, your patches are clean to go
into libgcal mainstream. Again, if you can, I suggest to base yourself
using the gitorious repository, since it has a better and cleaner
interface for me to handle merge requests.


Adenilson

On Fri, Aug 27, 2010 at 7:30 PM, Chris Frey <cd...@fo...> wrote:
> Thanks.  I've updated my repo.or.cz fork with your latest gitorious code,
> and rebased my code on top of it.
>
> The main google page for libgcal still points to repo.or.cz.
>
> - Chris
>
>
> On Fri, Aug 27, 2010 at 07:03:38PM -0400, Adenilson Cavalcanti wrote:
>> Chris
>>
>> The current devel repo of libgcal is:
>> http://gitorious.org/libgcal
>>
>> I will remove the link to or.cz soon...
>>
>>
>> Regards
>>
>>
>> Adenilson
>>
>> On Fri, Aug 27, 2010 at 6:19 PM, Chris Frey <cd...@fo...> wrote:
>> > On Wed, Aug 25, 2010 at 02:10:03PM -0400, Chris Frey wrote:
>> >> On Wed, Aug 25, 2010 at 01:52:12PM -0400, Adenilson Cavalcanti wrote:
>> >> > > Perhaps libgcal needs a cleanup function of its own, that the application
>> >> > > should call when closing. ?i.e. the sample apps should call libgcal's
>> >> > > cleanup function, which then calls xmlCleanupParser().
>> >> >
>> >> > Maybe adding a call to it when the gcal_t context is destroyed?
>> >>
>> >> I think it should be a separate call, because an application might be
>> >> finished with libgcal but not finished with libxml2, and needs to have
>> >> control over when libxml2 goes away.
>> >
>> > Hi Adenilson,
>> >
>> > I believe you're super busy, so I've taken the liberty of creating
>> > a forked repo on repo.or.cz to push my changes to. ?I've added
>> > the above cleanup fix, added the examples to the tree, added
>> > a final cleanup function (as well as added it to the examples),
>> > and added a new gcal_delete_entry_url() call.
>> >
>> > Please give them a look. ?Hopefully they are clean enough that you can
>> > just pull and release, but if not, let me know what needs fixing.
>> >
>> > Forked repo:
>> >
>> > ? ? ? ?http://repo.or.cz/w/libgcal/libgcal-cdf.git
>> >
>> > Thanks,
>> > - Chris
>> >
>> >
>>
>> ------------------------------------------------------------------------------
>> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
>> Be part of this innovative community and reach millions of netbook users
>> worldwide. Take advantage of special opportunities to increase revenue and
>> speed time-to-market. Join now, and jumpstart your future.
>> http://p.sf.net/sfu/intel-atom-d2d
>> _______________________________________________
>> Opensync-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

Thanks.  I've updated my repo.or.cz fork with your latest gitorious code,
and rebased my code on top of it.

The main google page for libgcal still points to repo.or.cz.

- Chris


On Fri, Aug 27, 2010 at 07:03:38PM -0400, Adenilson Cavalcanti wrote:
> Chris
> 
> The current devel repo of libgcal is:
> http://gitorious.org/libgcal
> 
> I will remove the link to or.cz soon...
> 
> 
> Regards
> 
> 
> Adenilson
> 
> On Fri, Aug 27, 2010 at 6:19 PM, Chris Frey <cd...@fo...> wrote:
> > On Wed, Aug 25, 2010 at 02:10:03PM -0400, Chris Frey wrote:
> >> On Wed, Aug 25, 2010 at 01:52:12PM -0400, Adenilson Cavalcanti wrote:
> >> > > Perhaps libgcal needs a cleanup function of its own, that the application
> >> > > should call when closing. ?i.e. the sample apps should call libgcal's
> >> > > cleanup function, which then calls xmlCleanupParser().
> >> >
> >> > Maybe adding a call to it when the gcal_t context is destroyed?
> >>
> >> I think it should be a separate call, because an application might be
> >> finished with libgcal but not finished with libxml2, and needs to have
> >> control over when libxml2 goes away.
> >
> > Hi Adenilson,
> >
> > I believe you're super busy, so I've taken the liberty of creating
> > a forked repo on repo.or.cz to push my changes to. ?I've added
> > the above cleanup fix, added the examples to the tree, added
> > a final cleanup function (as well as added it to the examples),
> > and added a new gcal_delete_entry_url() call.
> >
> > Please give them a look. ?Hopefully they are clean enough that you can
> > just pull and release, but if not, let me know what needs fixing.
> >
> > Forked repo:
> >
> > ? ? ? ?http://repo.or.cz/w/libgcal/libgcal-cdf.git
> >
> > Thanks,
> > - Chris
> >
> >
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

[Adenilson C. <cav...@gm...>]

Chris

The current devel repo of libgcal is:
http://gitorious.org/libgcal

I will remove the link to or.cz soon...


Regards


Adenilson

On Fri, Aug 27, 2010 at 6:19 PM, Chris Frey <cd...@fo...> wrote:
> On Wed, Aug 25, 2010 at 02:10:03PM -0400, Chris Frey wrote:
>> On Wed, Aug 25, 2010 at 01:52:12PM -0400, Adenilson Cavalcanti wrote:
>> > > Perhaps libgcal needs a cleanup function of its own, that the application
>> > > should call when closing. ?i.e. the sample apps should call libgcal's
>> > > cleanup function, which then calls xmlCleanupParser().
>> >
>> > Maybe adding a call to it when the gcal_t context is destroyed?
>>
>> I think it should be a separate call, because an application might be
>> finished with libgcal but not finished with libxml2, and needs to have
>> control over when libxml2 goes away.
>
> Hi Adenilson,
>
> I believe you're super busy, so I've taken the liberty of creating
> a forked repo on repo.or.cz to push my changes to.  I've added
> the above cleanup fix, added the examples to the tree, added
> a final cleanup function (as well as added it to the examples),
> and added a new gcal_delete_entry_url() call.
>
> Please give them a look.  Hopefully they are clean enough that you can
> just pull and release, but if not, let me know what needs fixing.
>
> Forked repo:
>
>        http://repo.or.cz/w/libgcal/libgcal-cdf.git
>
> Thanks,
> - Chris
>
>

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

On Wed, Aug 25, 2010 at 02:10:03PM -0400, Chris Frey wrote:
> On Wed, Aug 25, 2010 at 01:52:12PM -0400, Adenilson Cavalcanti wrote:
> > > Perhaps libgcal needs a cleanup function of its own, that the application
> > > should call when closing. ?i.e. the sample apps should call libgcal's
> > > cleanup function, which then calls xmlCleanupParser().
> > 
> > Maybe adding a call to it when the gcal_t context is destroyed?
> 
> I think it should be a separate call, because an application might be
> finished with libgcal but not finished with libxml2, and needs to have
> control over when libxml2 goes away.

Hi Adenilson,

I believe you're super busy, so I've taken the liberty of creating
a forked repo on repo.or.cz to push my changes to.  I've added
the above cleanup fix, added the examples to the tree, added
a final cleanup function (as well as added it to the examples),
and added a new gcal_delete_entry_url() call.

Please give them a look.  Hopefully they are clean enough that you can
just pull and release, but if not, let me know what needs fixing.

Forked repo:

	http://repo.or.cz/w/libgcal/libgcal-cdf.git

Thanks,
- Chris

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

On Wed, Aug 25, 2010 at 01:52:12PM -0400, Adenilson Cavalcanti wrote:
> > Perhaps libgcal needs a cleanup function of its own, that the application
> > should call when closing. ?i.e. the sample apps should call libgcal's
> > cleanup function, which then calls xmlCleanupParser().
> 
> Maybe adding a call to it when the gcal_t context is destroyed?

I think it should be a separate call, because an application might be
finished with libgcal but not finished with libxml2, and needs to have
control over when libxml2 goes away.

- Chris

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

[Adenilson C. <cav...@gm...>]

Chris


>
> But I did test it in opensync, and it fixes a segfault that took me about
> 6 hours to find.  When you call xmlCleanupParser(), it frees the type
> table, which may be in use by other code.  Inside schema context pointers,
> there is a baseType pointer which points to a global list of types.
> These types disappear when some other code calls xmlCleanupParser().

I see.

>
> Perhaps libgcal needs a cleanup function of its own, that the application
> should call when closing.  i.e. the sample apps should call libgcal's
> cleanup function, which then calls xmlCleanupParser().
>

Maybe adding a call to it when the gcal_t context is destroyed?


Cheers


Adenilson

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

Hi Adenilson,

I haven't tested it with valgrind, and I'm sure there will be memory
leaks without it.

But I did test it in opensync, and it fixes a segfault that took me about
6 hours to find.  When you call xmlCleanupParser(), it frees the type
table, which may be in use by other code.  Inside schema context pointers,
there is a baseType pointer which points to a global list of types.
These types disappear when some other code calls xmlCleanupParser().

Perhaps libgcal needs a cleanup function of its own, that the application
should call when closing.  i.e. the sample apps should call libgcal's
cleanup function, which then calls xmlCleanupParser().

- Chris


On Wed, Aug 25, 2010 at 11:51:26AM -0400, Adenilson Cavalcanti wrote:
> Chris
> 
> Thanks for sending a patch (generally I will
> 
> Have you tested it with the client example code here (4 examples):
> http://code.google.com/p/libgcal/
> 
> while running inside Valgrind? I'm used to test it for memory leaks...
> 
> 
> Regards
> 
> 
> Adenilson
> 
> On Tue, Aug 24, 2010 at 11:41 PM, Chris Frey <cd...@fo...> wrote:
> > Hi Adenilson,
> >
> > Could you apply this patch to libgcal-0.9.5 and release 0.9.6 soon?
> > If libgcal calls xmlCleanupParser() it ends up freeing all the schema
> > types internally, and if other code is using them (such as opensync and
> > the xmlformat plugin), it causes a segfault.
> >
> > Thanks,
> > - Chris
> >
> >
> >
> > Subject: [PATCH] Don't cleanup the entire libxml parser... other app code may still be using it
> >
> > ---
> > ?src/gcal_parser.c | ? ?3 ---
> > ?1 files changed, 0 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/gcal_parser.c b/src/gcal_parser.c
> > index 437d6ac..f1aa13c 100644
> > --- a/src/gcal_parser.c
> > +++ b/src/gcal_parser.c
> > @@ -103,7 +103,6 @@ int get_the_url(char *data, int length, char **url)
> > ? ? ? ? ? ? ? ?result = 0;
> >
> > ? ? ? ?xmlFreeDoc(doc);
> > - ? ? ? xmlCleanupParser();
> >
> > ?exit:
> > ? ? ? ?return result;
> > @@ -160,7 +159,6 @@ int get_edit_url(char *data, int length, char **url)
> > ? ? ? ? ? ? ? ?result = 0;
> >
> > ? ? ? ?xmlFreeDoc(doc);
> > - ? ? ? xmlCleanupParser();
> >
> > ?exit:
> > ? ? ? ?return result;
> > @@ -183,7 +181,6 @@ int get_edit_etag(char *data, int length, char **url)
> > ? ? ? ? ? ? ? ?result = 0;
> >
> > ? ? ? ?xmlFreeDoc(doc);
> > - ? ? ? xmlCleanupParser();
> >
> > ?exit:
> > ? ? ? ?return result;
> > --
> > 1.7.0.3
> >
> >
> >
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel

Re: [Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

[Adenilson C. <cav...@gm...>]

Chris

Thanks for sending a patch (generally I will

Have you tested it with the client example code here (4 examples):
http://code.google.com/p/libgcal/

while running inside Valgrind? I'm used to test it for memory leaks...


Regards


Adenilson

On Tue, Aug 24, 2010 at 11:41 PM, Chris Frey <cd...@fo...> wrote:
> Hi Adenilson,
>
> Could you apply this patch to libgcal-0.9.5 and release 0.9.6 soon?
> If libgcal calls xmlCleanupParser() it ends up freeing all the schema
> types internally, and if other code is using them (such as opensync and
> the xmlformat plugin), it causes a segfault.
>
> Thanks,
> - Chris
>
>
>
> Subject: [PATCH] Don't cleanup the entire libxml parser... other app code may still be using it
>
> ---
>  src/gcal_parser.c |    3 ---
>  1 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/src/gcal_parser.c b/src/gcal_parser.c
> index 437d6ac..f1aa13c 100644
> --- a/src/gcal_parser.c
> +++ b/src/gcal_parser.c
> @@ -103,7 +103,6 @@ int get_the_url(char *data, int length, char **url)
>                result = 0;
>
>        xmlFreeDoc(doc);
> -       xmlCleanupParser();
>
>  exit:
>        return result;
> @@ -160,7 +159,6 @@ int get_edit_url(char *data, int length, char **url)
>                result = 0;
>
>        xmlFreeDoc(doc);
> -       xmlCleanupParser();
>
>  exit:
>        return result;
> @@ -183,7 +181,6 @@ int get_edit_etag(char *data, int length, char **url)
>                result = 0;
>
>        xmlFreeDoc(doc);
> -       xmlCleanupParser();
>
>  exit:
>        return result;
> --
> 1.7.0.3
>
>
>

[Opensync-devel] [PATCH] Important fix to libgcal-0.9.5

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

Hi Adenilson,

Could you apply this patch to libgcal-0.9.5 and release 0.9.6 soon?
If libgcal calls xmlCleanupParser() it ends up freeing all the schema
types internally, and if other code is using them (such as opensync and
the xmlformat plugin), it causes a segfault.

Thanks,
- Chris



Subject: [PATCH] Don't cleanup the entire libxml parser... other app code may still be using it

---
 src/gcal_parser.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/src/gcal_parser.c b/src/gcal_parser.c
index 437d6ac..f1aa13c 100644
--- a/src/gcal_parser.c
+++ b/src/gcal_parser.c
@@ -103,7 +103,6 @@ int get_the_url(char *data, int length, char **url)
 		result = 0;
 
 	xmlFreeDoc(doc);
-	xmlCleanupParser();
 
 exit:
 	return result;
@@ -160,7 +159,6 @@ int get_edit_url(char *data, int length, char **url)
 		result = 0;
 
 	xmlFreeDoc(doc);
-	xmlCleanupParser();
 
 exit:
 	return result;
@@ -183,7 +181,6 @@ int get_edit_etag(char *data, int length, char **url)
 		result = 0;
 
 	xmlFreeDoc(doc);
-	xmlCleanupParser();
 
 exit:
 	return result;
-- 
1.7.0.3

Re: [Opensync-devel] libsyncml and SWIG

[griffin <gr...@ub...>]

michael,

i'd like to add SWIG support to the libsyncml library (so that i can
use it in a python client and/or server), but wanted to check with you
and the rest of the libsyncml team to make sure that this makes sense
to do... some questions:

- is there a better way or a library that you are aware of that
   would be better suited? ie. is adding SWIG to libsyncml the clearly
   wrong thing to do because of architectural incompatibility, or
   replication of synonymous code already out there?

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

- do you mind if i work on adding SWIG to libsyncml?

any help/pointers appreciated!... :)

chris,

thanks for the response - i did not have michael's email until i realized
that opensync-devel was archived... thanks!


On Tue, 24 Aug 2010 15:11:08 -0400, Chris Frey <cd...@fo...>  
wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users
> worldwide. Take advantage of special opportunities to increase revenue  
> and
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel