Menu
▾
▴
opensync-devel
|
From: deloptes <del...@ya...> - 2010-10-28 20:46:59
|
Hi,
for pity I've found out that the current solution works for contacts very
well, but for the other types and particularly when using more then one it
is producing errors. Especially after rejecting a forecast.
I'm trying to find out why and I thing it is context related, but first of
all I'm not sure where I have to set userdata (
osync_objtype_sink_set_userdata ( sink, this ); ) in the syncbase class or
in the derived classes? Or it doesn't matter. the second question is how it
is supposed to set context info and sink. Can someone with more programming
experience give me a hint. After thinking a lot in he past days I think it
is correct to put it in the base class and not as it is now - in the
derived classes.
the second question is in general about how ctx,info etc are passed to the
subclass - dereferencing. where should it take place? I've added also
sb->setSink(sink); to the WRAP makro and the function in the manner of the
rest
#define WRAP() \
osync_trace( TRACE_ENTRY, "%s(%p,%p, %p, %p)", __PRETTY_FUNCTION__, sink,
info, ctx, userdata); \
SinkBase *sb = reinterpret_cast<SinkBase*>(userdata); \
sb->setSink(sink);\
sb->setPluginInfo( info );\
sb->setContext( ctx );
...
void SinkBase::setSink(OSyncObjTypeSink *sink)
{
Q_ASSERT( mSink == 0 || sink == mSink );
mSink = sink;
}
another option would be to move the wrap(sink) call from the derived into
the base class instead setting the mSink, but what is in wrap sink must be
set at init, so may be I'll just leave it. I started looking into barryenv
to see how it is handling the env, but was busy and did not move further.
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?
thanks
|
|
From: deloptes <del...@ya...> - 2011-01-08 18:40:16
|
deloptes wrote:
> Hi,
>
> for pity I've found out that the current solution works for contacts very
> well, but for the other types and particularly when using more then one it
> is producing errors. Especially after rejecting a forecast.
>
> I'm trying to find out why and I thing it is context related, but first of
> all I'm not sure where I have to set userdata (
> osync_objtype_sink_set_userdata ( sink, this ); ) in the syncbase class or
> in the derived classes? Or it doesn't matter. the second question is how
> it is supposed to set context info and sink. Can someone with more
> programming experience give me a hint. After thinking a lot in he past
> days I think it is correct to put it in the base class and not as it is
> now - in the derived classes.
>
> the second question is in general about how ctx,info etc are passed to the
> subclass - dereferencing. where should it take place? I've added also
> sb->setSink(sink); to the WRAP makro and the function in the manner of
> the rest
>
> #define WRAP() \
> osync_trace( TRACE_ENTRY, "%s(%p,%p, %p, %p)", __PRETTY_FUNCTION__,
> sink,
> info, ctx, userdata); \
> SinkBase *sb = reinterpret_cast<SinkBase*>(userdata); \
> sb->setSink(sink);\
> sb->setPluginInfo( info );\
> sb->setContext( ctx );
>
> ...
>
> void SinkBase::setSink(OSyncObjTypeSink *sink)
> {
> Q_ASSERT( mSink == 0 || sink == mSink );
> mSink = sink;
> }
>
For the record this was also fixed, though no one really answered here.
regards
|
|
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: 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: Chris F. <cd...@fo...> - 2011-01-16 19:17:34
|
On Sun, Jan 16, 2011 at 06:15:57PM +0100, deloptes wrote: > 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. I don't use Akonadi, so I'm going purely on your description here, but if the Revision number is always incremented every time an entry is edited, and only then, then that is a perfectly good number to use for the hash. > 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. Do you mean you are syncing the same akonadi with itself? That would cause problems, I guess. But if you're syncing one akonadi with a separate one, then how could the separate revision numbers be affected? I smell the scent of a bug here, but I don't know enough to say if it's just in my understanding. :-) - Chris |
|
From: deloptes <del...@ya...> - 2011-01-16 21:52:08
|
Chris Frey wrote: > Do you mean you are syncing the same akonadi with itself? That would > cause problems, I guess. But if you're syncing one akonadi with a > separate one, then how could the separate revision numbers be affected? > I smell the scent of a bug here, but I don't know enough to say if it's > just in my understanding. Thanks for replaying so fast. I use the akonadi engine or kontacts to create two address books and sync them. Revision is applied to each side separately. So it works in most cases. It would be better to apply some kind of content check i.e. in slow sync but I guess it is done internally anyway. I can not remember what the anchor was good for and also if it would be useful in this plugin. I think I remember to have read something about the slow sync ... but if something needs to be changes, my plan for such changes is, to be done later. regards |
|
From: Chris F. <cd...@fo...> - 2011-01-17 11:16:34
|
On Sun, Jan 16, 2011 at 10:51:40PM +0100, deloptes wrote: > Thanks for replaying so fast. I use the akonadi engine or kontacts to create > two address books and sync them. Revision is applied to each side > separately. So it works in most cases. It would be better to apply some > kind of content check i.e. in slow sync but I guess it is done internally > anyway. In slow sync, you have to send all the data anyway, so revision shouldn't matter. You'll just set them all to whatever means "clean state." > I can not remember what the anchor was good for and also if it would be > useful in this plugin. I think I remember to have read something about the > slow sync ... but if something needs to be changes, my plan for such > changes is, to be done later. Anchor, which was renamed to state_db, is juse a key/value storage mechanism for the plugins. It can be used for anything. Only use it if you need it. - Chris |
|
From: deloptes <del...@ya...> - 2011-01-19 21:49:16
|
Chris Frey wrote:
> On Sun, Jan 16, 2011 at 06:15:57PM +0100, deloptes wrote:
>> 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.
What I mean is exactly the example below. Notice the UID entry. I think I
need to do a mapping between the IDs of the devices or setting the RemoteID
to the UID when the former is missing. It is getting a bit complicated.
However the only difference is the UID, which is used in the hash.
I think I had the check for RemoteId in the code (and removed it for some
reason ... ). I need to code some better solution.
This behavior also depends in the way one syncs first. Is there data on the
phone or not and vice versa.
Member: 2 (akonadi-sync)
UID: dmY7a5NAzE
<?xml version="1.0"?>
<contact>
<EMail>
<Content>xxxxxxxxxxxxxx</Content>
</EMail>
<Name>
<LastName>xxxxxxxxxxxxxx</LastName>
<FirstName>xxxxxxxxxxxxxx</FirstName>
<Additional></Additional>
<Prefix></Prefix>
<Suffix></Suffix>
</Name>
<Revision>
<Content>20100723T191711Z</Content>
</Revision>
<Telephone Type="Cellular">
<Content>xxxxxxxxxxxxxx</Content>
</Telephone>
</contact>
Entry 2:
Member: 1 (syncml-obex-client)
UID: 48
<?xml version="1.0"?>
<contact>
<EMail Type="Internet">
<Content>xxxxxxxxxxxxxx</Content>
</EMail>
<Name>
<LastName>xxxxxxxxxxxxxx</LastName>
<FirstName>xxxxxxxxxxxxxx</FirstName>
<Additional></Additional>
<Prefix></Prefix>
<Suffix></Suffix>
</Name>
<Revision>
<Content>20100723T191711Z</Content>
</Revision>
<Telephone Type="Cellular">
<Content>xxxxxxxxxxxxxx</Content>
</Telephone>
</contact>
|
|
From: deloptes <del...@ya...> - 2011-01-19 23:01:33
|
deloptes wrote: > I think I had the check for RemoteId in the code (and removed it for some > reason ... ). I need to code some better solution. I had a look but the problem seem to be that in kde the UID is defined as qint64, so I need to find a way to solve it :-( ... to convert it regards |
Thanks for helping keep SourceForge clean.
X