Menu
▾
▴
opensync-devel — The place to coordinate the development of OpenSync
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(9) |
Apr
(84) |
May
(18) |
Jun
(12) |
Jul
(6) |
Aug
(7) |
Sep
(10) |
Oct
(31) |
Nov
(59) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(53) |
Feb
(15) |
Mar
(43) |
Apr
(40) |
May
(63) |
Jun
(142) |
Jul
(54) |
Aug
(31) |
Sep
(30) |
Oct
(39) |
Nov
(36) |
Dec
(64) |
| 2007 |
Jan
(128) |
Feb
(261) |
Mar
(156) |
Apr
(127) |
May
(76) |
Jun
(131) |
Jul
(83) |
Aug
(124) |
Sep
(83) |
Oct
(88) |
Nov
(180) |
Dec
(90) |
| 2008 |
Jan
(86) |
Feb
(93) |
Mar
(117) |
Apr
(104) |
May
(65) |
Jun
(35) |
Jul
(38) |
Aug
(111) |
Sep
(58) |
Oct
(33) |
Nov
(102) |
Dec
(194) |
| 2009 |
Jan
(193) |
Feb
(74) |
Mar
(111) |
Apr
(77) |
May
(31) |
Jun
(20) |
Jul
(1) |
Aug
(3) |
Sep
(57) |
Oct
(125) |
Nov
(50) |
Dec
(3) |
| 2010 |
Jan
(26) |
Feb
(5) |
Mar
(13) |
Apr
(3) |
May
(3) |
Jun
(12) |
Jul
(27) |
Aug
(47) |
Sep
(105) |
Oct
(53) |
Nov
(34) |
Dec
(21) |
| 2011 |
Jan
(115) |
Feb
(17) |
Mar
|
Apr
(6) |
May
(16) |
Jun
(15) |
Jul
(85) |
Aug
(21) |
Sep
(13) |
Oct
(12) |
Nov
(28) |
Dec
(23) |
| 2012 |
Jan
|
Feb
(13) |
Mar
(4) |
Apr
|
May
(1) |
Jun
(5) |
Jul
(5) |
Aug
(31) |
Sep
(8) |
Oct
|
Nov
|
Dec
(1) |
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(33) |
Sep
(9) |
Oct
(10) |
Nov
(2) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: deloptes <del...@ya...> - 2011-01-16 17:16:24
|
Chris Frey wrote: > On Thu, Oct 28, 2010 at 10:46:36PM +0200, deloptes wrote: >> I'll probably have to upload to svn my current version, but let me know >> first if there is a theoretical background. If I solve this I think it >> will be almost perfectly working. The other thing I want to implement is >> (in the manner of barry sync) using the id or remoteId of an item + >> revision to do the checking/finding etc of items. originally the author >> was using the id, which made it impossible to correlate by uid ... or was >> id intended to be "fake" id in the barry code? > > > Not sure I understand the question. The "fake hash" logic of the > Barry plugin only works because the BlackBerry keeps dirty flags of its > own for the database records. So if a record is dirty in the BlackBerry, > then I just increment the "hash", which makes it appear dirty to > OpenSync as well. > I think I've solved this with satisfactory results. I was confused by the "slow-sync" behavior, which I understood later and by the way the plugin handles the dirty flags (barry specific). The question was how to implement the check in akonadi because akonadi has a revision number which is incremented internally every time you edit the record. It has ID and RemoteID, so I was not sure what I should check. I'm still not sure the way I've implemented it is the best one, but for the time and stage of development it is also satisfactory. The current solution uses RemoteID for change-id and the Revision for the hash (hash = RemoteID+"-"+Revision. I am not sure if I need to keep a tack of the akonadiId. However I think this is only a problem when syncing akonadi with akonadi, because each of them increments Revision by 1 and on the next sync it reports change, but the content is the same. I don't know how it can be solved better. I was also not sure if revision can be handled as state in the statedb or anchor ... no sure right now (I've forgotten some of the details already :-) ) But if someone (or you want to discuss it I could have a look again. regards |
|
From: deloptes <del...@ya...> - 2011-01-16 16:27:25
|
Chris Frey wrote: > Are you asking whether there is something special if you set a change's > hashtable entry to a value of 0? I don't think so. It is only the > difference that matters. That is, when the hashtable changes from what it > was before, regardless of the actual values. yes this was my original question. thanks for the answer regads |
|
From: Daniel G. <go...@b1...> - 2011-01-15 14:48:52
|
On Saturday, January 15, 2011 12:59:27 pm Quentin Denis wrote: > Hi folks, > > may I ask you to verify this patch? Sure, sorry for the delay - was laid low with the flu. > Emanoil, do you now have access to > commit into the gnokii directory in SVN? I can give you commit access if you like. Just let me know your trac-user name (once again). > > With this patch I removed all the warnings, except the ones related to the > calendar support. Once you have approved my contact changes, I will apply > them on calendar since it's the same code. > > However, the plugin still not listed in osynctool. I am wondering if this > is because of the remaining warnings (only related to calendar then) or > because something fundamental is missing. Any idea? Tip how to root-cause such problems: Run: OSYNC_TRACE=/tmp/osync_trace/ OSYNC_PRINTERROR=1 osynctool --listplugins Applied your patch (gnokii2.patch) dgollub@marvin:~/projects/OpenSync/plugins/gnokii-sync/build> OSYNC_TRACE=/tmp/osync_trace/ OSYNC_PRINTERROR=1 osynctool -- listplugins ERROR: Unable to open module /home/dgollub/build/OpenSync/lib/libopensync1/plugins/gnokii-sync.so: /home/dgollub/build/OpenSync/lib/libopensync1/plugins/gnokii-sync.so: undefined symbol: osync_objtype_sink_get_slowsync EXIT_ERROR: osync_module_load: Unable to open module /home/dgollub/build/OpenSync/lib/libopensync1/plugins/gnokii-sync.so: /home/dgollub/build/OpenSync/lib/libopensync1/plugins/gnokii-sync.so: undefined symbol: osync_objtype_sink_get_slowsync [...] -- Daniel Gollub Linux Consultant & Developer Tel.: +49-160 47 73 970 Mail: go...@b1... B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 |
|
From: Quentin D. <que...@gm...> - 2011-01-15 11:59:40
|
Hi folks, may I ask you to verify this patch? Emanoil, do you now have access to commit into the gnokii directory in SVN? With this patch I removed all the warnings, except the ones related to the calendar support. Once you have approved my contact changes, I will apply them on calendar since it's the same code. However, the plugin still not listed in osynctool. I am wondering if this is because of the remaining warnings (only related to calendar then) or because something fundamental is missing. Any idea? I think most of the changes should be correct, but I would like to catch your attention to the modifcations I did in the get/commit_changes functions (gnokii_contact.c) with all the sink and format stuff changes. Please make sure everything is okay there. Best regards, Quentin On Tuesday 11 January 2011 12:32:49 Pawel Kot wrote: > Hi Quentin, > > On Tue, Jan 11, 2011 at 10:02, Quentin Denis <que...@gm...> wrote: > > 1st part: gnokii api changes: Pawel, how does the whole config work now? > > I > > Actually there's no change in here. There are new (better?) functions > to handle this which should give more flexibility. Still the old one > works and will work for some more time. > > > can't find any documentation about this on google, all I find out is > > that's deprecated (but still working?). Btw, there is a dead link to the > > wiki on the gnokii homepage, discovered that as I was looking for > > documentation > > Yes, wiki is down now unfortunately. I will look in detail on the > current code in the plugin and will propose non-deprecated solution. > > take care, |
|
From: Chris F. <cd...@fo...> - 2011-01-14 21:09:22
|
On Thu, Oct 28, 2010 at 10:46:36PM +0200, deloptes wrote: > I'll probably have to upload to svn my current version, but let me know > first if there is a theoretical background. If I solve this I think it will > be almost perfectly working. The other thing I want to implement is (in the > manner of barry sync) using the id or remoteId of an item + revision to do > the checking/finding etc of items. originally the author was using the id, > which made it impossible to correlate by uid ... or was id intended to > be "fake" id in the barry code? Not sure I understand the question. The "fake hash" logic of the Barry plugin only works because the BlackBerry keeps dirty flags of its own for the database records. So if a record is dirty in the BlackBerry, then I just increment the "hash", which makes it appear dirty to OpenSync as well. - Chris |
|
From: Chris F. <cd...@fo...> - 2011-01-14 21:03:07
|
On Sat, Oct 23, 2010 at 09:56:35PM +0200, deloptes wrote: > Do you know if hash = 0 has some special meaning in the hashtable/get change > type? Are you asking whether there is something special if you set a change's hashtable entry to a value of 0? I don't think so. It is only the difference that matters. That is, when the hashtable changes from what it was before, regardless of the actual values. - Chris |
|
From: Chris F. <cd...@fo...> - 2011-01-14 20:49:35
|
On Fri, Oct 15, 2010 at 10:30:21PM +0200, deloptes wrote: > Chris Frey wrote: > > > If the stack trace doesn't include function names, then you'll need to > > recompile the libraries with debug info enabled (gcc's -g flag). > > Last question - how do I do this in cmake > > everything I've tried shows no debug symbols in gdb Sorry for the late reply, but I encourage people to setup their cmake like I suggested in the Plugin Porting Howto from a while back, or at least use it as a base for their own config: http://opensync.org/wiki/devel/pluginPortingGuide-0.40 Cmake seems to hide things by default, which, for developers, is bad. - Chris |
|
From: Chris F. <cd...@fo...> - 2011-01-14 20:27:35
|
On Sat, Jan 08, 2011 at 12:30:44PM -0800, Emanoil Kotsev wrote: > 2. libopensync > > http://www.opensync.org/ticket/1442 > http://www.opensync.org/ticket/1444 - a problem in the parser (converter) breaks sync of contact data Can you grab the latest vformat plugin from SVN and give it a try? If it works, can you close the above tickets for me? :-) Thanks, - Chris |
|
From: Chris F. <cd...@fo...> - 2011-01-14 19:25:43
|
The xsltformat plugin already compiles for me, using the latest SVN. I'm not entirely sure that the plugin does much though. :-) - Chris On Thu, Jan 13, 2011 at 11:56:07PM +0100, deloptes wrote: > Suggestion for patch to fix the build of the xsl plugin > (I didn't have time too look deeper into the code, and need to find out how > to test it) > > $ diff -ubwN src/xsltformat.c.orig src/xsltformat.c > > --- src/xsltformat.c.orig 2011-01-13 23:49:46.000000000 +0100 > +++ src/xsltformat.c 2011-01-13 23:50:26.000000000 +0100 > @@ -97,7 +97,7 @@ > if (!format) > return FALSE; > > - osync_format_env_register_objformat(env, format); > + osync_format_env_register_objformat(env, format, error); > osync_objformat_unref(format); > > return TRUE; > @@ -144,7 +144,7 @@ > > osync_converter_set_initialize_func(conv, initialize_func); > osync_converter_set_finalize_func(conv, finalize_func); > - osync_format_env_register_converter(env, conv); > + osync_format_env_register_converter(env, conv, &error); > osync_converter_unref(conv); > > return TRUE; > @@ -171,14 +171,14 @@ > /* XSLT to xml-contact */ > result = reg_conv(env, xslt_contact, xml_contact, > conv_xslt_to_contact, > - initialize_xslt, finalize_xslt); > + initialize_xslt, > (OSyncFormatConverterFinalizeFunc) finalize_xslt); > if (!result) > return FALSE; > > /* xml-contact to XSLT */ > result = reg_conv(env, xml_contact, xslt_contact, > conv_contact_to_xslt, > - initialize_xslt, finalize_xslt); > + initialize_xslt, > (OSyncFormatConverterFinalizeFunc) finalize_xslt); > return result; > > } > > $ make > [100%] Building C object src/CMakeFiles/xsltformat_plugin.dir/xsltformat.o > Linking C shared module xsltformat_plugin.so > [100%] Built target xsltformat_plugin > > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Opensync-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensync-devel |
|
From: Chris F. <cd...@fo...> - 2011-01-14 19:23:21
|
On Fri, Jan 14, 2011 at 12:00:12AM +0100, deloptes wrote: > Q1: what is this option good for? > > <AdvancedOptions> > <AdvancedOption> > <DisplayName>Filter Categories</DisplayName> > <MaxOccurs>4294967295</MaxOccurs> > <Max>4294967295</Max> > <Name>FilterCategory</Name> > <Type>string</Type> > <Value></Value> > </AdvancedOption> > </AdvancedOptions> You can grep the code for "FilterCategory" and follow the trail. Looks like it is used to limit what categories of data are synced. Some handheld devices can sort their contacts and events into subcategories. - Chris |
|
From: deloptes <del...@ya...> - 2011-01-13 23:05:19
|
Q1: what is this option good for?
<AdvancedOptions>
<AdvancedOption>
<DisplayName>Filter Categories</DisplayName>
<MaxOccurs>4294967295</MaxOccurs>
<Max>4294967295</Max>
<Name>FilterCategory</Name>
<Type>string</Type>
<Value></Value>
</AdvancedOption>
</AdvancedOptions>
Q2: This is not working, but I will try to find time next week to test
building on squeeze with trinity. If I get the same error I'll open a
ticket
osynctool --discover test-file
/opt/software/opensync/libopensync/opensync/capabilities/opensync_capabilities.c:277:E:osync_capabilities_set_format:
Assertion "capsformat" failed
Aborted
regards
|
|
From: deloptes <del...@ya...> - 2011-01-13 22:56:55
|
Suggestion for patch to fix the build of the xsl plugin
(I didn't have time too look deeper into the code, and need to find out how
to test it)
$ diff -ubwN src/xsltformat.c.orig src/xsltformat.c
--- src/xsltformat.c.orig 2011-01-13 23:49:46.000000000 +0100
+++ src/xsltformat.c 2011-01-13 23:50:26.000000000 +0100
@@ -97,7 +97,7 @@
if (!format)
return FALSE;
- osync_format_env_register_objformat(env, format);
+ osync_format_env_register_objformat(env, format, error);
osync_objformat_unref(format);
return TRUE;
@@ -144,7 +144,7 @@
osync_converter_set_initialize_func(conv, initialize_func);
osync_converter_set_finalize_func(conv, finalize_func);
- osync_format_env_register_converter(env, conv);
+ osync_format_env_register_converter(env, conv, &error);
osync_converter_unref(conv);
return TRUE;
@@ -171,14 +171,14 @@
/* XSLT to xml-contact */
result = reg_conv(env, xslt_contact, xml_contact,
conv_xslt_to_contact,
- initialize_xslt, finalize_xslt);
+ initialize_xslt,
(OSyncFormatConverterFinalizeFunc) finalize_xslt);
if (!result)
return FALSE;
/* xml-contact to XSLT */
result = reg_conv(env, xml_contact, xslt_contact,
conv_contact_to_xslt,
- initialize_xslt, finalize_xslt);
+ initialize_xslt,
(OSyncFormatConverterFinalizeFunc) finalize_xslt);
return result;
}
$ make
[100%] Building C object src/CMakeFiles/xsltformat_plugin.dir/xsltformat.o
Linking C shared module xsltformat_plugin.so
[100%] Built target xsltformat_plugin
|
|
From: deloptes <del...@ya...> - 2011-01-12 19:26:58
|
http://www.opensync.org/wiki/hackers Plugins [...] file-sync (1) [...] kdepim-sync (1) [...] 1 Core plugins. Problems with these will block releases What is the problem with file-sync exactly and whos supporting kdepim-sync. I could have a look into kdepim-sync as I'm using currently kde3 and I'll probably use it in the near future. regards |
|
From: Emanoil K. <del...@ya...> - 2011-01-11 12:17:24
|
Hi,
--- On Tue, 1/11/11, Quentin Denis <que...@gm...> wrote:
>
> 1st part: gnokii api changes: Pawel, how does the whole
> config work now? I
> can't find any documentation about this on google, all I
> find out is that's
> deprecated (but still working?). Btw, there is a dead link
> to the wiki on the
> gnokii homepage, discovered that as I was looking for
> documentation
>
> 2nd part: OSyncSink issues in the plugin. I don't know how
> to fix this yet
>
> 3rd part: the issues I mentioned in my first mail with
> calendar and contacts:
> objformat and so on in the commit/get_changes functions. I
> have looked at
> other plugins how to solve it but I would need someone to
> revise patches I
> would provide later on.
It's probably the same as for the akonadi and the other plugins that need to fit the new osync api. if you need an assistance - let me know.
>
> Small bracket on SyncML: Emanoil, you know my issue with
> SyncML. I would be
> glad to provide the necessary information to solve that
> issue, and if I could
> I would even lend you my phone, but I am technically not
> able to fix the
> syncml code.
>
I'm sorry but I have already forgotten what your problem with syncml was - sorry but I was fixed on my one.
regards
|
|
From: Pawel K. <paw...@gm...> - 2011-01-11 11:33:16
|
Hi Quentin, On Tue, Jan 11, 2011 at 10:02, Quentin Denis <que...@gm...> wrote: > 1st part: gnokii api changes: Pawel, how does the whole config work now? I Actually there's no change in here. There are new (better?) functions to handle this which should give more flexibility. Still the old one works and will work for some more time. > can't find any documentation about this on google, all I find out is that's > deprecated (but still working?). Btw, there is a dead link to the wiki on the > gnokii homepage, discovered that as I was looking for documentation Yes, wiki is down now unfortunately. I will look in detail on the current code in the plugin and will propose non-deprecated solution. take care, -- Pawel Kot |
|
From: Quentin D. <que...@gm...> - 2011-01-11 09:02:16
|
Ok, from the compilation output I can deduce the following: 1st part: gnokii api changes: Pawel, how does the whole config work now? I can't find any documentation about this on google, all I find out is that's deprecated (but still working?). Btw, there is a dead link to the wiki on the gnokii homepage, discovered that as I was looking for documentation 2nd part: OSyncSink issues in the plugin. I don't know how to fix this yet 3rd part: the issues I mentioned in my first mail with calendar and contacts: objformat and so on in the commit/get_changes functions. I have looked at other plugins how to solve it but I would need someone to revise patches I would provide later on. Small bracket on SyncML: Emanoil, you know my issue with SyncML. I would be glad to provide the necessary information to solve that issue, and if I could I would even lend you my phone, but I am technically not able to fix the syncml code. Regards, Quentin On Monday 10 January 2011 21:30:43 Emanoil Kotsev wrote: > Quentin Denis wrote: > > Here is a patch to make the gnokii plugin compile against the latest api. > > However, the plugin does not register yet and there are still warnings > > during compilation but I think this patch is a good starting point. Could > > anyone commit the changes since I have no access to svn? > > I couldn't apply the patch, but I had a look into the code and the messages > below > > it looks like the code does not fit the recent gnokii*.h definitions, so > much more needs to be done. > > Daniel, do you intend to work on the code in (near) future? > > gnokii could provide contact and calendar sync (if we are lucky). > > Does someone know if it would work with symbian? > > here the warnings > > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config > .c: In function ‘gnokii_config_parse’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_confi > g.c:173: warning: ‘gn_cfg_memory_read’ is deprecated (declared at > /usr/include/gnokii.h:266) > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_confi > g.c:173: warning: passing argument 1 of ‘gn_cfg_memory_read’ from > incompatible pointer type /usr/include/gnokii.h:266: note: expected ‘const > char **’ but argument is of type ‘char **’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_confi > g.c:174: warning: ‘gn_cfg_phone_load’ is deprecated (declared at > /usr/include/gnokii.h:273) [ 77%] Building C object > src/CMakeFiles/gnokii-sync.dir/gnokii_sync.o > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c: In function ‘initialize’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:199: warning: passing argument 2 of ‘osync_objtype_sink_set_connect_func’ > from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:615: note: expected ‘OSyncSinkConnectFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:200: warning: passing argument 2 of > ‘osync_objtype_sink_set_disconnect_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:629: note: expected ‘OSyncSinkDisconnectFn’ but argument is of > type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:215: warning: passing argument 2 of > ‘osync_objtype_sink_set_get_changes_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:617: note: expected ‘OSyncSinkGetChangesFn’ but argument is of > type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:216: warning: passing argument 2 of ‘osync_objtype_sink_set_commit_func’ > from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:619: note: expected ‘OSyncSinkCommitFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *, struct > OSyncChange *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:217: warning: passing argument 2 of > ‘osync_objtype_sink_set_sync_done_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:625: note: expected ‘OSyncSinkSyncDoneFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:248: warning: passing argument 2 of > ‘osync_objtype_sink_set_get_changes_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:617: note: expected ‘OSyncSinkGetChangesFn’ but argument is of > type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:249: warning: passing argument 2 of ‘osync_objtype_sink_set_commit_func’ > from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:619: note: expected ‘OSyncSinkCommitFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *, struct > OSyncChange *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:250: warning: passing argument 2 of > ‘osync_objtype_sink_set_sync_done_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:625: note: expected ‘OSyncSinkSyncDoneFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c: In function ‘get_sync_info’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:296: warning: passing argument 2 of ‘osync_plugin_set_discover’ from > incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_plugin > .h:237: note: expected ‘discover_fn’ but argument is of type ‘osync_bool > (*)(void *, struct OSyncPluginInfo *, struct OSyncError **)’ [ 88%] > Building C object src/CMakeFiles/gnokii-sync.dir/gnokii_calendar.o > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c: In function ‘gnokii_calendar_get_changes’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:345: warning: initialization makes pointer from integer without a > cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:355: warning: initialization makes pointer from integer without a > cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c: In function ‘gnokii_calendar_commit_change’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:476: warning: initialization makes pointer from integer without a > cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:477: warning: initialization makes pointer from integer without a > cast [100%] Building C object > src/CMakeFiles/gnokii-sync.dir/gnokii_contact.o > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c: In function ‘gnokii_contact_get_changes’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:393: warning: initialization makes pointer from integer without a cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:396: warning: initialization makes pointer from integer without a cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c: In function ‘gnokii_contact_commit_change’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:562: warning: initialization makes pointer from integer without a cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:563: warning: initialization makes pointer from integer without a cast > Linking C shared module gnokii-sync.so > [100%] Built target gnokii-sync |
|
From: Pawel K. <paw...@gm...> - 2011-01-10 22:58:16
|
Hi, On Mon, Jan 10, 2011 at 21:30, Emanoil Kotsev <del...@ya...> wrote: > Quentin Denis wrote: > >> Here is a patch to make the gnokii plugin compile against the latest api. >> However, the plugin does not register yet and there are still warnings >> during compilation but I think this patch is a good starting point. Could >> anyone commit the changes since I have no access to svn? > > I couldn't apply the patch, but I had a look into the code and the messages below > > it looks like the code does not fit the recent gnokii*.h definitions, so much more needs to be done. I do not think a lot has changed in gnokii API. There were indeed some changes but nothing that would prevent gnokii plugin from working. In any case I'm happy to assist you with updates or make gnokii API more useful to you. take care, -- Pawel Kot |
|
From: Emanoil K. <del...@ya...> - 2011-01-10 22:38:14
|
Ok thanks for the research, I thought you have exams :-). Focus on them! --- On Mon, 1/10/11, Quentin Denis <que...@gm...> wrote: > Date: Monday, January 10, 2011, 10:17 PM > I am aware of those warnings, but I > though that fixing the plugin api was a > good start. start to where is teh question - it looks to me like a dead end! That much on free software :D I still cant believe that no one is syncing his f**king phone with linux ... or what kind of phones are using those guys. I was using siemens c or s55 - great phone it was syncing well untill it fall appart after 4 years of use, then the dark ages started for me. I had nokia and business phone sonyerr that I couldn't sync with each other because of incompatibility if the property fields ... and I've got constantly double entries. I gave it up and focused on writing my thesis. 2years ago I was done and last year came to this project, because, now, the smart phones are on the market over two years and .... no one is syncing. I don't want to believe this - really! > > I don't know if Daniel will update his plugin. I have > already asked him but > absence of response pushed me to have a look at the code by > myself. He > certainly has a better knowledge of the gnokii api and > would fix it much > faster than I would. However, in my desperate case of > syncing my phone I saw > this opportunity as being a good start to learn about > plugins and maybe write > my own gammu plugin later on (I know a bit about its api > because of > kmobiletools). > > Symbian phones: > http://www.gnokii.org/docs.shtml#symbian > Gammu does not do much better: > http://wammu.eu/docs/faq/#symbian > because of a lack of C++ knowledge > (http://blog.cihar.com/archives/2007/06/27/gammu_and_symbian_3rd_generation/) > I would prefer to focus on one thing at a time. we are busy anyway. Perhaps it's much better to support Michael to fix the syncml and for you it would be probably better to work on the kitchensync, so that configure can work from the gui. I could also help here and there. If any one is successfully using osynctool for syncing a phone with kde3 or 4, please, give me an example? By phone I mean something that went on the market in the past 2 years thanks and regards |
|
From: Quentin D. <que...@gm...> - 2011-01-10 21:20:59
|
I am aware of those warnings, but I though that fixing the plugin api was a good start. I don't know if Daniel will update his plugin. I have already asked him but absence of response pushed me to have a look at the code by myself. He certainly has a better knowledge of the gnokii api and would fix it much faster than I would. However, in my desperate case of syncing my phone I saw this opportunity as being a good start to learn about plugins and maybe write my own gammu plugin later on (I know a bit about its api because of kmobiletools). Symbian phones: http://www.gnokii.org/docs.shtml#symbian Gammu does not do much better: http://wammu.eu/docs/faq/#symbian because of a lack of C++ knowledge (http://blog.cihar.com/archives/2007/06/27/gammu_and_symbian_3rd_generation/) On Monday 10 January 2011 21:30:43 Emanoil Kotsev wrote: > Quentin Denis wrote: > > Here is a patch to make the gnokii plugin compile against the latest api. > > However, the plugin does not register yet and there are still warnings > > during compilation but I think this patch is a good starting point. Could > > anyone commit the changes since I have no access to svn? > > I couldn't apply the patch, but I had a look into the code and the messages > below > > it looks like the code does not fit the recent gnokii*.h definitions, so > much more needs to be done. > > Daniel, do you intend to work on the code in (near) future? > > gnokii could provide contact and calendar sync (if we are lucky). > > Does someone know if it would work with symbian? > > here the warnings > > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config > .c: In function ‘gnokii_config_parse’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_confi > g.c:173: warning: ‘gn_cfg_memory_read’ is deprecated (declared at > /usr/include/gnokii.h:266) > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_confi > g.c:173: warning: passing argument 1 of ‘gn_cfg_memory_read’ from > incompatible pointer type /usr/include/gnokii.h:266: note: expected ‘const > char **’ but argument is of type ‘char **’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_confi > g.c:174: warning: ‘gn_cfg_phone_load’ is deprecated (declared at > /usr/include/gnokii.h:273) [ 77%] Building C object > src/CMakeFiles/gnokii-sync.dir/gnokii_sync.o > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c: In function ‘initialize’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:199: warning: passing argument 2 of ‘osync_objtype_sink_set_connect_func’ > from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:615: note: expected ‘OSyncSinkConnectFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:200: warning: passing argument 2 of > ‘osync_objtype_sink_set_disconnect_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:629: note: expected ‘OSyncSinkDisconnectFn’ but argument is of > type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:215: warning: passing argument 2 of > ‘osync_objtype_sink_set_get_changes_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:617: note: expected ‘OSyncSinkGetChangesFn’ but argument is of > type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:216: warning: passing argument 2 of ‘osync_objtype_sink_set_commit_func’ > from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:619: note: expected ‘OSyncSinkCommitFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *, struct > OSyncChange *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:217: warning: passing argument 2 of > ‘osync_objtype_sink_set_sync_done_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:625: note: expected ‘OSyncSinkSyncDoneFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:248: warning: passing argument 2 of > ‘osync_objtype_sink_set_get_changes_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:617: note: expected ‘OSyncSinkGetChangesFn’ but argument is of > type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:249: warning: passing argument 2 of ‘osync_objtype_sink_set_commit_func’ > from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:619: note: expected ‘OSyncSinkCommitFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *, struct > OSyncChange *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:250: warning: passing argument 2 of > ‘osync_objtype_sink_set_sync_done_func’ from incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtyp > e_sink.h:625: note: expected ‘OSyncSinkSyncDoneFn’ but argument is of type > ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’ > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c: In function ‘get_sync_info’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync. > c:296: warning: passing argument 2 of ‘osync_plugin_set_discover’ from > incompatible pointer type > /opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_plugin > .h:237: note: expected ‘discover_fn’ but argument is of type ‘osync_bool > (*)(void *, struct OSyncPluginInfo *, struct OSyncError **)’ [ 88%] > Building C object src/CMakeFiles/gnokii-sync.dir/gnokii_calendar.o > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c: In function ‘gnokii_calendar_get_changes’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:345: warning: initialization makes pointer from integer without a > cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:355: warning: initialization makes pointer from integer without a > cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c: In function ‘gnokii_calendar_commit_change’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:476: warning: initialization makes pointer from integer without a > cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calen > dar.c:477: warning: initialization makes pointer from integer without a > cast [100%] Building C object > src/CMakeFiles/gnokii-sync.dir/gnokii_contact.o > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c: In function ‘gnokii_contact_get_changes’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:393: warning: initialization makes pointer from integer without a cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:396: warning: initialization makes pointer from integer without a cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c: In function ‘gnokii_contact_commit_change’: > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:562: warning: initialization makes pointer from integer without a cast > /home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_conta > ct.c:563: warning: initialization makes pointer from integer without a cast > Linking C shared module gnokii-sync.so > [100%] Built target gnokii-sync |
|
From: Emanoil K. <del...@ya...> - 2011-01-10 20:30:51
|
Quentin Denis wrote:
> Here is a patch to make the gnokii plugin compile against the latest api.
> However, the plugin does not register yet and there are still warnings
> during compilation but I think this patch is a good starting point. Could
> anyone commit the changes since I have no access to svn?
I couldn't apply the patch, but I had a look into the code and the messages below
it looks like the code does not fit the recent gnokii*.h definitions, so much more needs to be done.
Daniel, do you intend to work on the code in (near) future?
gnokii could provide contact and calendar sync (if we are lucky).
Does someone know if it would work with symbian?
here the warnings
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c: In function ‘gnokii_config_parse’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c:173: warning: ‘gn_cfg_memory_read’ is deprecated (declared at /usr/include/gnokii.h:266)
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c:173: warning: passing argument 1 of ‘gn_cfg_memory_read’ from incompatible pointer type
/usr/include/gnokii.h:266: note: expected ‘const char **’ but argument is of type ‘char **’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_config.c:174: warning: ‘gn_cfg_phone_load’ is deprecated (declared at /usr/include/gnokii.h:273)
[ 77%] Building C object src/CMakeFiles/gnokii-sync.dir/gnokii_sync.o
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c: In function ‘initialize’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:199: warning: passing argument 2 of ‘osync_objtype_sink_set_connect_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:615: note: expected ‘OSyncSinkConnectFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:200: warning: passing argument 2 of ‘osync_objtype_sink_set_disconnect_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:629: note: expected ‘OSyncSinkDisconnectFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:215: warning: passing argument 2 of ‘osync_objtype_sink_set_get_changes_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:617: note: expected ‘OSyncSinkGetChangesFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:216: warning: passing argument 2 of ‘osync_objtype_sink_set_commit_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:619: note: expected ‘OSyncSinkCommitFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *, struct OSyncChange *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:217: warning: passing argument 2 of ‘osync_objtype_sink_set_sync_done_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:625: note: expected ‘OSyncSinkSyncDoneFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:248: warning: passing argument 2 of ‘osync_objtype_sink_set_get_changes_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:617: note: expected ‘OSyncSinkGetChangesFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:249: warning: passing argument 2 of ‘osync_objtype_sink_set_commit_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:619: note: expected ‘OSyncSinkCommitFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *, struct OSyncChange *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:250: warning: passing argument 2 of ‘osync_objtype_sink_set_sync_done_func’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_objtype_sink.h:625: note: expected ‘OSyncSinkSyncDoneFn’ but argument is of type ‘void (*)(void *, struct OSyncPluginInfo *, struct OSyncContext *)’
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c: In function ‘get_sync_info’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_sync.c:296: warning: passing argument 2 of ‘osync_plugin_set_discover’ from incompatible pointer type
/opt/testing/opensync/include/libopensync1/opensync/plugin/opensync_plugin.h:237: note: expected ‘discover_fn’ but argument is of type ‘osync_bool (*)(void *, struct OSyncPluginInfo *, struct OSyncError **)’
[ 88%] Building C object src/CMakeFiles/gnokii-sync.dir/gnokii_calendar.o
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calendar.c: In function ‘gnokii_calendar_get_changes’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calendar.c:345: warning: initialization makes pointer from integer without a cast
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calendar.c:355: warning: initialization makes pointer from integer without a cast
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calendar.c: In function ‘gnokii_calendar_commit_change’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calendar.c:476: warning: initialization makes pointer from integer without a cast
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_calendar.c:477: warning: initialization makes pointer from integer without a cast
[100%] Building C object src/CMakeFiles/gnokii-sync.dir/gnokii_contact.o
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_contact.c: In function ‘gnokii_contact_get_changes’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_contact.c:393: warning: initialization makes pointer from integer without a cast
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_contact.c:396: warning: initialization makes pointer from integer without a cast
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_contact.c: In function ‘gnokii_contact_commit_change’:
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_contact.c:562: warning: initialization makes pointer from integer without a cast
/home/yoki/opensync/libopensync-plugin-gnokii/gnokii-sync/src/gnokii_contact.c:563: warning: initialization makes pointer from integer without a cast
Linking C shared module gnokii-sync.so
[100%] Built target gnokii-sync
|
|
From: Chris F. <cd...@fo...> - 2011-01-10 20:14:19
|
On Mon, Jan 10, 2011 at 04:17:51PM +0100, Lukas Zeller wrote: > Yes, I apprechiate that! I am just trying to explain a bit why we came > to the current licensing / contributor model. What I have a hard time > with is getting thrown into the same pot with multinational companies, > as a two man, entirely self funded, all risk private micro venture. I > beg to realize that this makes a difference, and not all options IBM > can safely take are automatically feasible for us. It's not my intention to judge you or your business model. It appears to be working for you, and I'm glad that you are making a living at it. I'm just trying to point out how it looks from the outside. And unfortunately, with the contributor agreement, the priority of helping with libsynthesis does tend to fall to the bottom of my (rather long) list. We can only do what makes sense to each of us. Best wishes, - Chris |
|
From: Michael B. <mic...@cm...> - 2011-01-10 16:42:11
|
On 01/10/11 15:47, Emanoil Kotsev wrote: > >> >> Android uses UTF-16 and does not specify the character set >> in the WBXML >> document. So the user of the library must set the character >> set via the >> interface. > > I do understand now. Do you know if they are using xerces? xerces people argueed for UTF-16. Their argumentation is reasonable. No idea. I just saw a libxml package at the Android repository but they also import many Apache packages. Nevertheless I failed with AndroidManifest.xml (yes, they use the usual xml suffix for binary XML files). I asked on #android if somebody knows details about Androids binary XML but nobody answers until now. Best regards Michael -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB |
|
From: Lukas Z. <lu...@pl...> - 2011-01-10 15:18:14
|
Hello Chris, On Jan 10, 2011, at 0:04 , Chris Frey wrote: > On Sun, Jan 09, 2011 at 05:58:42PM +0100, Lukas Zeller wrote: >> But maybe the point is something different - as much as I agree with >> the goals of free software, I'm not so sure about the total insurance >> attitute that sometimes accompanies it. I mean, if the current licensing >> terms are a problem for someone who would like to actually *do* something, >> please let me know. But expecting from me to risk 10 (full time!) years >> first, so that maybe eventually somebody could feel more inclined to >> considering contributing with zero risk... Not really. > > My original email in this thread was meant to let you know. :-) Yes, I apprechiate that! I am just trying to explain a bit why we came to the current licensing / contributor model. What I have a hard time with is getting thrown into the same pot with multinational companies, as a two man, entirely self funded, all risk private micro venture. I beg to realize that this makes a difference, and not all options IBM can safely take are automatically feasible for us. > To me, a contributor agreement, of any kind, says to the community that > the LGPL is good enough for them, but not good enough for the author. LGPL alone simply did not fit our situation. They have their shlib border way to define derived work, and according to that, all our commercial products would have to become opensource. As much as I would like to be able to dedicate all of my work entirely to opensource, I haven't arrived at an arrangement that would allow me to do so, without committing commercial suicide. I'm not saying such an arrangement is impossible, but I'm saying I haven't found it yet. Ideas welcome. We've considered all sorts of ways, and arrived at LGPL+CA exactly for the reason because the community does not like derived licenses, but wants FSF original licenses (or so we were told at that time in 2009). > Basically, it is a big sign saying that the author wants to work alone. It could be read as such when looked at it without any context. I hope however I could give the context to explain that this interpretation is more that wrong regarding libsynthesis - the reason is the real-world history of the project. A full-time venture of two people over 10 years now, with (I repeat) no cent public money burnt in the process. Sacrificing the business that pays for it to correct the impurity of the current licensing is just out of proportions, and would hurt everyone, us and the community alike. I'd understand the criticism more if we chose GPL, so forcing everyone else to open their complete applications while we could keep them closed. But with LGPL we're offering the same potential for building commercial apps to everyone. The only reason that's not "good enough" for us is that our (pre-existing!) products are statically linked with some or all code of what today's libsynthesis is. It's just not possible to rewrite all of them (the day has 24 hours here as well). Users adpting libsynthesis in its OS form can't possibly have these sorts of dependencies, so what the CA provides us extra is a non-value for everyone except us. > For example, I never dreamed of contributing to MySQL, even though I > used the free version regularly. About the most I might have done was > report a bug. I only did that once in an area that affected me, but I > didn't bother working up a patch. The contributor agreement / closed > nature of MySQL was a real factor in deciding not to pursue writing a > patch. Aagain I beg to take scale into account. If we were anywhere near the size of MySQL AB at that time, or had shareholders only waiting to draw away profit from your contributions, I'd understand the concern. I know, I'm stressing the point a bit, but essentially this is what makes tiny companies that take their own risk reluctant to try with open source. You get compared with the most powerful commercial entities, and expected to exceed their abilities to take risks (they all have CAs or tailored licenses, but you may not). > There's only so much time in the day, and sometimes seemingly small > issues like licenses and paperwork or lack of trust sway the balance > in certain directions. And sometimes money sways it in the other. > Of course, there are business reasons why the dual license / contributor > agreement path is taken, and if actual money is being made, hey, that > works. And in some cases the suits force these decisions on the programmers > too. But the money is instead of contributions. Nobody can contribute anything without his or her living supported by money. So anybody has to take care about that, somehow. I find it a bit strange that making that money "elsewhere" (hidden from the community) should be more noble, and thus more worth contributions. Both approaches are IMHO equal compromises needed in today's economy. To correct that means digging into how wages, taxes, money in general do or should work, a discussion I'm most interested in but is definitely OT here. Lukas Zeller |
|
From: Michael B. <mic...@cm...> - 2011-01-10 15:02:52
|
Hi, does somebody know the location of the WBXML specification of Android's manifest? There is an open ticket #52 but I have no idea what's going on. Best regards Michael -- ___________________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 70143 ZE Computer- und Medienservice Fax: +49 (0)30-2093 70135 Unter den Linden 6 mic...@cm... D-10099 Berlin ___________________________________________________________________ PGP Fingerprint: 09E4 3D29 4156 2774 0F2C C643 D8BD 1918 2030 5AAB |
|
From: Emanoil K. <del...@ya...> - 2011-01-10 14:47:42
|
>
> Android uses UTF-16 and does not specify the character set
> in the WBXML
> document. So the user of the library must set the character
> set via the
> interface.
I do understand now. Do you know if they are using xerces? xerces people argueed for UTF-16. Their argumentation is reasonable.
it seems you have to add an option in the case of libwbxml. Perhaps it will be useful for other devices too - like my nokia. I've seen here that charsets are provided in dependance of the OS version/language you install/use.
I.e. Nokia phones in Bulgaria/Russia etc. would have cyryllic interface supporting cyrillic input (and UTF), German interfaces do not support cyrillic input but can display cyrillic (added in UTF on kde3). The question here for nokia is how would I edit those entries ... but I guess you don't have the answer.
I always say charencoding is Babylon of modern computing - hopefully everything except UTF will be forbidden/unacceptable in near future.
regards
|
90 messages has been excluded from this view by a project administrator.
