<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.misc.opensync.devel">
    <title>gmane.comp.misc.opensync.devel</title>
    <link>http://blog.gmane.org/gmane.comp.misc.opensync.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4885"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4880"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4853"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4831"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4829"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4828"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4810"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4809"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4806"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4802"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4793"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4792"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4762"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4741"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4740"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4739"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4737"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4735"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4722"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4720"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4885">
    <title>[codehelp&lt; at &gt;debian.org: Status of opensync in Debian - mass removal very likely]</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4885</link>
    <description>&lt;pre&gt;Dear opensync folks,

I guess this may be of interest for you - if you are interested in
keeping opensync in Debian I would ask you to get in contact with the
maintainers (http://packages.qa.debian.org/o/opensync.html).

Kind regards
Harald Jenny

----- Forwarded message from Neil Williams &amp;lt;codehelp&amp;lt; at &amp;gt;debian.org&amp;gt; -----

Date: Sat, 3 Mar 2012 23:15:16 +0000
From: Neil Williams &amp;lt;codehelp&amp;lt; at &amp;gt;debian.org&amp;gt;
To: debian-devel&amp;lt; at &amp;gt;lists.debian.org
Cc: Robert Collins &amp;lt;robertc&amp;lt; at &amp;gt;robertcollins.net&amp;gt;, Michael Banck &amp;lt;mbanck&amp;lt; at &amp;gt;debian.org&amp;gt;, Matthias Jahn &amp;lt;jahn.matthias&amp;lt; at &amp;gt;freenet.de&amp;gt;, Jonny Lamb &amp;lt;jonny&amp;lt; at &amp;gt;debian.org&amp;gt;
Subject: Status of opensync in Debian - mass removal very likely
X-Local-Spam-Level: 
X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu)

opensync/multisync is a complete mess, collecting 25 RC bugs between 20
source packages and a collective 17,626 days waiting to enter testing.
dd-list attached.

Summary:
libopensync-plugin-gnokii1462 days old (needed 10 days)libopensync0RC x 2
libopensync-plugin-gpe1462 days &lt;/pre&gt;</description>
    <dc:creator>Harald Jenny</dc:creator>
    <dc:date>2012-03-05T08:11:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4880">
    <title>syncML devel equipment</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4880</link>
    <description>&lt;pre&gt;Hi,

What phone or device is recommended to do syncML development?
All I have are blackberries, and I don't think they support it.

- Chris


------------------------------------------------------------------------------
Virtualization &amp;amp; Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2012-02-23T22:41:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4853">
    <title>Q: osync strings glib vs libstd</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4853</link>
    <description>&lt;pre&gt;Hi,
I have a theoretical question rather general as I have been doing a lot of
programming for text processing purposes and always had troubles with
encodings, so I was wondering what should one use when coding for opensync.
There are several advantages when using glib, but also several disadvantages
compared to libstd.

Can you please advise? Or where can I post this question if this is not the
right place for that discussion?

regards


------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of 
discussion for anyone considering optimizing the pricing and packaging model 
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
&lt;/pre&gt;</description>
    <dc:creator>deloptes</dc:creator>
    <dc:date>2011-12-08T11:28:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4831">
    <title>EBook / ECal new API</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4831</link>
    <description>&lt;pre&gt;Hi,

In helping friends with the last Fedora release, I have noticed that the
ebook / ecal API was modified.

http://www.opensubscriber.com/message/evolution-hackers&amp;lt; at &amp;gt;gnome.org/15214566.html

http://developer.gnome.org/libebook/stable/EBook.html#e-book-free-change-list

We have to worked to adapt opensync evolution2 plugin for the new
Evolution API... Maybe opensync evolution3 plugin :)

Regards,

Nicolas



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
&lt;/pre&gt;</description>
    <dc:creator>Nicolas</dc:creator>
    <dc:date>2011-11-20T14:54:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4829">
    <title>May I modify libwbxml-0.11.0 source code to make it compile, and use it in commercial software</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4829</link>
    <description>&lt;pre&gt;Hi,

My question is related to LGPL licensing of libwbxml-0.11.0.

I got the source of libwbxml-0.11.0 but found it won't compile on Windows
using Visual C++ 6 (missing wbxml_config.h). I'd like to modify the source
and make it compile, then use it in the commercial software in a
dynamic-link manner(DLL).  This proprietary is an email client with
ActiveSync capability.

My concern is that as it's bounded by LGPL, may I keep the commercial
software code proprietary, while using a modified libwbxml-0.11.0 ?

My modification is just to make it compile, but not to modify the internal
of libwbxml.

Is this a case prohibited by LGPL, a close source commercial software dynamic
links to a modified version of LGPL software?

Thanks!

*Weiming*
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.&lt;/pre&gt;</description>
    <dc:creator>Zeng,Weiming</dc:creator>
    <dc:date>2011-11-14T07:27:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4828">
    <title>Cmake Modules repo</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4828</link>
    <description>&lt;pre&gt;http://zi.fi/cmake/Modules/


------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
&lt;/pre&gt;</description>
    <dc:creator>deloptes</dc:creator>
    <dc:date>2011-11-10T11:58:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4810">
    <title>Discussion: syncml plugin with synthesis</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4810</link>
    <description>&lt;pre&gt;Hi, guys, I'm thinking about writing a plugin that uses the synthesis
engine.
I read about synthesis last year, but I was busy with too many business
stuff to work on something like this.

My proposal is to discuss it here and I'm asking for input basically to work
out the design.
opensync side, so I need some ideas how synthesis can be brought into the
game.

I was thinking perhaps to take over the syncml library, but it looks like
there is too much SyncML stuff to care about, which is already done in
synthesis.

If one of you is interested to assist, please let me know.

Your opinion and estimates are really appreciated.

regards


------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning&amp;lt; at &amp;gt;Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev&lt;/pre&gt;</description>
    <dc:creator>deloptes</dc:creator>
    <dc:date>2011-10-23T10:40:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4809">
    <title>file renames to resolve version conflicts</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4809</link>
    <description>&lt;pre&gt;Hi,

The following commits have been added to the opensync git repo, to resolve
naming conflicts between opensync 0.2x packages and 0.4x packages:


commit 0a1eb5c84b641a02fa75f507844172f9a5d891d9
Author: Chris Frey &amp;lt;cdfrey&amp;lt; at &amp;gt;foursquare.net&amp;gt;
Date:   Thu Oct 20 00:03:33 2011 -0400

    Renamed python module to opensync1, so it can coexist with 0.2x

commit 1f9e2f3852ee206a2fea506d248a0f006bba4659
Author: Chris Frey &amp;lt;cdfrey&amp;lt; at &amp;gt;foursquare.net&amp;gt;
Date:   Wed Oct 19 23:50:45 2011 -0400

    Renamed some internal variables in osync1plugin to match new program name

commit 46825b649f531899b8623aa4050f84692e8da839
Author: Chris Frey &amp;lt;cdfrey&amp;lt; at &amp;gt;foursquare.net&amp;gt;
Date:   Wed Oct 19 23:49:21 2011 -0400

    Renamed tools from osync* to osync1*, so they can coexist with 0.2x



I think this is a good move for python, since the API changed anyway.
And for the tools/ renames, these are mostly debug and development tools
anyway, so I don't see much impact.

Let me know if you think differently.

Thanks,
- Chris


---------------------&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-10-20T04:09:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4806">
    <title>fixed: evolution syncing problem with get_changeson Debian Squeeze</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4806</link>
    <description>&lt;pre&gt;Hi,

Thought I should post this here as well.  The evolution-data-server
distributed with Debian Squeeze (stable) has a bug in the addressbook
get_changes call, and therefore does not return any changes even if
some were made in evolution.

The patch is available here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641898

I hope that the next point release of Squeeze will have this fixed, as
well as in Ubuntu.

- Chris


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-09-23T05:12:16</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4802">
    <title>make test doubts</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4802</link>
    <description>&lt;pre&gt;Hello,

I'm trying to run some of the opensync test (make test) but with no luck
inside the binary-meta.
Is the "make test" supposed to be executed after or before a make install?

If before, make test just fails for every test because it misses some
libraries like inside rootdir/lib and other that are
only inside builddir, like libopensync-testing.so.

If it is supposed to run after the "make install", why this exists in
file-sync test?

ADD_TEST( check_data ${CMAKE_CURRENT_SOURCE_DIR}/check_data
${CMAKE_BINARY_DIR} )

It uses the CMAKE_BINARY_DIR, which is the build dir. Inside the test, this
argument is used for pluginpath suffixed with src:

PLUGINPATH="$1/src"

Clearly, this expects to run before install.


Maybe a "test" target inside the binary-meta makefile would be interesting.
However, it would need to set some env vars as
LD_LIBRARY_PATH and PATH to the respective ones inside source/rootdir.

Another solution would be to set this env inside the test specs, like:

ADD_TEST( check_data ${CMAKE_CURRE&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-09-02T15:52:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4793">
    <title>[BUG] Fix printf for size_t on google-calendar</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4793</link>
    <description>&lt;pre&gt;Hello,

This is a simple fix in order to have google-calendar compile on x86_64.

git&amp;lt; at &amp;gt;github.com:luizluca/google-calendar.git fixprintf

Regards,
---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-08-27T02:10:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4792">
    <title>Binary meta fails at "make fetch"</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4792</link>
    <description>&lt;pre&gt;Hello Chris,

I just got a cellphone (and now I can play again with opensync). It is
a simple samsung C3200 that does not work
with any tool under linux. :-)

I saw that binary-meta now has more interesting make options. I tried
"make fetch" from a clean git
and got this error:

(...)
Receiving objects: 100% (747/747), 211.94 KiB | 93 KiB/s, done.
Resolving deltas: 100% (539/539), done.
Submodule path 'sources/kdepim': checked out
'8a793cfb5e07a6f7443cdd00d8de18cdf0bf1b5c'
fatal: destination path 'sources/opensync' already exists and is not
an empty directory.
Clone of 'git://repo.or.cz/opensync/opensync-cdf.git' into submodule
path 'sources/opensync' failed
make: ** [fetch] Erro 1

Again just for sure:

# make fetch
git submodule init
git submodule update
fatal: destination path 'sources/opensync' already exists and is not
an empty directory.
Clone of 'git://repo.or.cz/opensync/opensync-cdf.git' into submodule
path 'sources/opensync' failed
make: ** [fetch] Erro 1

So I discovered that something before crea&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-08-26T15:02:46</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4762">
    <title>libopensync with AMQP</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4762</link>
    <description>&lt;pre&gt;Hello,

I have a question and i don’t know if it makes sense. Please do
correct me, if i am wrong.

Can you use libopensync along with zeromq/rabbitmq (rabbitmq is a AMQP
protocol implementation with zeromq being AFAIK loosely based on AMQP)
to syncornize data with another server that uses liopensync to
synchronize random data ??

Or is it better to use libsyncml to sync arbitary binary data some
media like ethernet.


Thanks,
Harish

------------------------------------------------------------------------------
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
&lt;/pre&gt;</description>
    <dc:creator>harish badrinath</dc:creator>
    <dc:date>2011-07-28T13:00:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4741">
    <title>Breakthrough: all opensync library tests pass</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4741</link>
    <description>&lt;pre&gt;Hi folks,

I did a test run on opensync tonight, using my git repo, and for the
first time to my memory, in all my experience with opensync, all
the tests pass for me.

Please let me know if you have different results.

It's been a long week of valgrind work, and repairing and debugging tests,
but I'm pretty happy that I'm at this point already.

This is not to say that all the tests are themselves accurate.  I haven't
gone through them and analyzed the logic.  I just wanted the existing
code to run and pass.

Hopefully from now on, we can keep opensync in this good shape.  And
improve it.  There are more corner cases, I'm sure, that valgrind can
catch.

The repo is here, with 65 commits over the past week and a half:

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


So far, all my tests have been with file-sync and mock-sync.  Next on
the agenda is to slowly work through the binary-meta tree, and test
those plugins with valgrind as well.  Hopefully opensync will become
bulletproof soon. :-)

Enjoy,
- Chris
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-23T06:15:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4740">
    <title>trying to understand the duplicate callback</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4740</link>
    <description>&lt;pre&gt;Hi Daniel,

While fixing leaks, I ran across the following function in the xmlformat
plugin:

http://repo.or.cz/w/opensync/xmlformat-cdf.git/commitdiff/d6bf4461281d96bfeb4bc593a087c04c6e232d3f

I've removed all the dead code (which contained a leak), but while it looks
correct, and the sync continues to work without that dead code, it looks
kinda odd.

I just wanted to confirm:  is is true that the duplicate callback is only
for duplicating the UID?  Why is there an output/outsize mechanism involved
in that case?

How else can the duplicate callback be used?

Thanks!
- Chris


------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks &amp;amp; Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-22T22:46:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4739">
    <title>API behaviour change: osync_xmlformat_assemble(and heads-up to ldap plugin author)</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4739</link>
    <description>&lt;pre&gt;Hi,

I've made a memory allocation change to the function
osync_xmlformat_assemble() which can be viewed here:

http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/b80405e0eafb0cebf1c034d9f08ceff778bf4fe3

Much of the code that I've seen, both inside the library and in the
plugins, assumes that the resulting buffer from a call to
osync_xmlformat_assemble() can be freed with osync_free() or g_free().

But the call passes back memory that expects to be freed with libxml2's
xmlFree().

If you're on a system that uses malloc everywhere, this might not matter,
but glib/gtk uses its own g_slice memory management, and this might
cause problems.

With the above commit, osync_xmlformat_assemble() gives back an osync_strdup()
buffer, so freeing works as expected.


scriptor:
I've noticed in your ldap plugin code, you free this memory with
calls to xmlFree(), which is very correct, but plugins shouldn't
have to know this.  This change will affect you.

Also, I notice that you make much use of valgrind in your &lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-22T22:40:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4737">
    <title>API change: capabilities API reworked</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4737</link>
    <description>&lt;pre&gt;Hi,

I've made a number of changes and fixed some memory leaks in the capabilities
API.  You can see the last change here:

http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/a826a3ce69bd1e84beca7344c18e2a0047306960

I've updated the evolution2, vformat, and xmlformat plugins as well, with
the small API change required, since I'm tracking them.

For plugin authors, the change is pretty simple:

Change: osync_capability_new()

To: osync_capabilities_add_new_capability()

and

Change: osync_capabilities_objtype_new()

To: osync_capabilieis_add_new_objtype()

The reason for this change was because the capabilities API behaved
differently than the rest of opensync.  The _new() calls would add
the new object to an internal list, and return an unref'd pointer.
This is inconsistent with what the user will expect from every other
_new() call in the library.

Also, due to this oddity, some of the internal implementations were
very difficult to get right.  While building the capabiities hierarchy,
there coul&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-18T21:34:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4735">
    <title>OMA DM</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4735</link>
    <description>&lt;pre&gt;There was mention on the roadmap of the wiki that there was some effort and
interest for device management - has there been any work, and are there any
working reference code for showing the capability.
------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensync-devel
&lt;/pre&gt;</description>
    <dc:creator>James Hanley</dc:creator>
    <dc:date>2011-07-18T17:06:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4722">
    <title>[BUG]s file-sync misses dir references and adouble random number</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4722</link>
    <description>&lt;pre&gt;Hello,

I don't know it the bug tracker at the site is still valid so I'm writing
about the bug I found to the list.
Correct me if I'm wrong.

File-sync/src/file-sync.c at osync_filesync_initialize:

"OSyncFileEnv *env" is initialized with no problem. It contains only a list
of "GList *directories". However, this list is never filled.
At the end of each sink loop, it should add dir to env-&amp;gt;directories. The
result is that free_env never frees dirs as
it has no reference for them.


File-sync/src/file.c at conv_plain_to_file:

file-&amp;gt;path = osync_rand_str(g_random_int_range(1, 100), error);

the g_random_int_range(1, 100) returns a random number between 1 and 100.
However, the osync_rand_str already does this. Its first argument is "int
maxlength", which is used in:

length = g_random_int_range(1, maxlength + 1);

Seems to be a double random :-). It should be enough to call:

file-&amp;gt;path = osync_rand_str(100, error);


Regards,

---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com
-------------&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-07-18T00:06:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4720">
    <title>FormatEnv setup and teardown logic</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4720</link>
    <description>&lt;pre&gt;Hi Daniel,

I've been working on opensync memory leaks, and found an interesting one
in the FormatEnv unref code:

http://repo.or.cz/w/opensync/opensync-cdf.git/commitdiff/9fcebe4abc933e256fa65bfbb2c1f4936c3966ff

For caps_converters, it looks like it is possible to have init/final logic
in the format plugins, since these functions exist:

osync_caps_converter_set_initialize_func()
osync_caps_converter_set_finalize_func()
osync_caps_converter_initialize()
osync_caps_converter_finalize()

The FormatEnv code does not seem to make use of any of these calls,
so my memory leak patch above does not call finalize().

The merger code on the other hand, only has the following functions
in opensync_merger.c:

osync_merger_set_initialize_func()
osync_merger_set_finalize_func()

There are no functions available to call these callbacks.

Could you give me a bird's eye overview of how the caps_converters and
mergers are supposed to work from an API point of view?  Should I be
implementing init/final sequences in For&lt;/pre&gt;</description>
    <dc:creator>Chris Frey</dc:creator>
    <dc:date>2011-07-16T01:41:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.misc.opensync.devel/4717">
    <title>[PATCH] Small memoryleak fixed in serializer.c</title>
    <link>http://comments.gmane.org/gmane.comp.misc.opensync.devel/4717</link>
    <description>&lt;pre&gt;Hello,

While playing with valgrind, I found some small memory leaks.
I fixed what it found in serializer.c and another one that it did not
found. My code is in:

git://github.com/luizluca/opensync-luizluca.git   fix-memoryleak-serializer

The first do some formatting cleanup (kdeveloper help) and the other
ones are the real fixes.

BTW, there is more memory leaks in code. I just didn't stopped to fix them.

Regards,

---
     Luiz Angelo Daros de Luca, Me.
            luizluca&amp;lt; at &amp;gt;gmail.com

------------------------------------------------------------------------------
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on "Lean Startup 
Secrets Revealed." This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
_______________________________________________
Opensync-devel mailing list
Opensync-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.ne&lt;/pre&gt;</description>
    <dc:creator>Luiz Angelo Daros de Luca</dc:creator>
    <dc:date>2011-07-15T05:15:21</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.misc.opensync.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.misc.opensync.devel</link>
  </textinput>
</rdf:RDF>

