you get? Have you checked
that all of the development files it depends on are installed? This is
documented in the SyncEvolution README (at the bottom, under compiling
from source) and the Synthesis README.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only
be on your link line
after libsynthesis. What's the complete command line of your final link
step?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
On Fri, 2009-07-03 at 01:39 -0700, Chen, Congwu wrote:
Lukas, could you help provide your opinion?
Lukas merged this into synthesis.ch repo and I merged it into
moblin.org.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee
this
way.
I'm not sure I follow here. Suppose a database plugin implements the
current DeleteSyncSet(). How does the engine know how many items were
deleted? Is it possible without causing overhead (the main reason for
the existance of DeleteSyncSync(), I suppose)?
--
Best Regards, Patrick Ohly
of VStr(), which is a globally visible function.
The other approach is to change VStr() and VPeeledStr() so that they
work with arbitrary line ends. Any thoughts on this?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel
On Wed, 2009-07-29 at 15:10 +0100, Patrick Ohly wrote:
On Tue, 2009-07-28 at 21:37 +0100, Patrick Ohly wrote:
[old revision of EXDATE conversion]
Does that look right?
Hah, no-one dared to say anything! You missed your chance to spot a
weakness in the code above, caught by the SyncEvolution
, lastmask, startIndex, endIndex,
true))
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel
Lukas wants to track this in the Synthesis tracker is a
different question. It would be useful because then I could add a link
to it into the patch that we carry in our master branch, saying
something like needed while this upstream feature request is open.
--
Best Regards, Patrick Ohly
(like a Waiting... immediately followed
by Processing...).
Anyway, I don't want any events generated in my case. If you think that
the engine shouldn't be invoked at all in this situation, then I'll
change our flow logic in SyncEvolution.
--
Best Regards, Patrick Ohly
The content
On Thu, 2009-07-30 at 18:15 +0200, Patrick Ohly wrote:
Now for the server, based on which information does the server generate
the SAN? We would have to start the server with its own local
configuration, then define the URIs on a specific device that match with
the ones configured
On Tue, 2009-09-22 at 21:06 +0100, Lukas Zeller wrote:
Hello Patrick,
On Sep 22, 2009, at 17:45 , Patrick Ohly wrote:
Hello Lukas!
Thanks a lot! Now we just need to figure out how to enable
lenientMode
for specific servers in SyncEvolution.
On Mon, 2009-09-21 at 18:02 +0100
, at least for the HTTP server case. Thanks!
On Sep 21, 2009, at 15:09 , Patrick Ohly wrote:
On Thu, 2009-07-30 at 18:15 +0200, Patrick Ohly wrote:
[...] That of course simplifies the generation of a SAN package on
the server,
but it raises the question how the client can synchronize
-test to trigger the endless 222 loop with
Funambol, assuming that the loop detection is removed? I want to
double-check that the real loop is still detected.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements
a possibility to do that in the DB layer, at least not with
the old code.
For a server that does not need any checking, just put a return TRUE
into logininitscript.
That works. I added it to SyncEvolution master.
--
Best Regards, Patrick Ohly
The content of this message is my personal
would avoid on opening ul, so the
indention would be right, too.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized
On Fri, 2009-11-13 at 11:47 +, Lukas Zeller wrote:
On Nov 10, 2009, at 18:43 , Patrick Ohly wrote:
There are quite a bit of changes in your luz branch and some unmerged
ones in our master. Should we merge the changes back and forth so that
we are in sync again?
Probably yes. Now
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
into that zone. Yes, this is error
prone. Yes, it can break for recurring events in foreign time zones.
Stupid phones.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's
for anyone except SyncEvolution, though, because of
extensions like X-EVOLUTION-UI-SLOT.
Comments?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue
)
+# if ONOFF_REGEX_SUPPORT
+# define REGEX_SUPPORT 1
+# else
+# undef REGEX_SUPPORT
+# endif
+#endif
// - server does support target options
#define SYSYNC_TARGET_OPTIONS 1
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee
is slow.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
On Tue, 2009-12-15 at 17:34 +0100, Patrick Ohly wrote:
As that doesn't seem to work, I'll look at using ABORTSESSION() in
addition to flagging individual datastores as bad. If I can properly
abort the session without affecting good datastores then this might be
a suitable solution.
This works
On Sat, 2009-12-12 at 13:38 +, Lukas Zeller wrote:
Hi Patrick,
On Dec 11, 2009, at 15:15 , Patrick Ohly wrote:
On Fri, 2009-12-11 at 14:55 +0100, Patrick Ohly wrote:
One possibility is to use scripting. In a script for a datatstore I
might be able to use ABORTDATASTORE
On Tue, 2009-12-15 at 17:10 +, Patrick Ohly wrote:
But when both datastores are told to do an unexpected slow sync, then
only the first alertscript is executed, then the whole session is
taken down immediately because of the ABORTSESSION() in it. For the
second datastore I end up
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
BEGIN:VCALENDAR
PRODID
syncmode only exposes twoway, from server only, from
client only).
Any hints?
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Hermuelheimer Strasse 8a Phone: +49-2232-2090-30
50321 Bruehl Fax
overhead.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
On Mi, 2010-01-27 at 11:50 +, Lukas Zeller wrote:
On Jan 27, 2010, at 12:24 , Patrick Ohly wrote:
Second - I don't really see why declaring it static would mean
anything for initialisation (apart from the fact that gcc seems not to
be able to figure out it should complain about
other than switching to slow sync (for two-way alert)
or to refresh (for a one-way), which it already does.
The server wouldn't do it automatically. It would stop and ask the user
how to proceed - this is our personal SyncML server which has a GUI.
--
Best Regards, Patrick Ohly
The content
.
Right.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
it, if necessary.
What is the expected outcome? IMHO, the server should do a
refresh-from-client.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue
On Di, 2010-02-02 at 09:18 +, Lukas Zeller wrote:
Hello Patrick,
On Feb 1, 2010, at 17:12 , Patrick Ohly wrote:
I've started splitting up the XML sample configs into individual files.
The first step just rearranges the content of the
src/sysync_SDK/configs. Patch in xml-config
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
On Fr, 2010-02-05 at 15:11 +, Lukas Zeller wrote:
Hello Patrick,
On Feb 5, 2010, at 11:45 , Patrick Ohly wrote:
Lukas, can you merge our master branch? I cannot rebase because the
scripts mentioned above depend on the commit ID.
Ok, but are you sure these are pushed?
No, I
that the static_castTBinfileDSConfig
*(*pos) is invalid for super datastores. Does that sound plausible?
I verified that the
TBinfileClientConfig::findOrCreateTargetIndexByDBInfo() is indeed for
the superdatastore by comparing the aLocalDBTypeID.
--
Best Regards, Patrick Ohly
The content of this message is my
On Do, 2010-02-11 at 17:19 +, Lukas Zeller wrote:
On Feb 11, 2010, at 13:44 , Patrick Ohly wrote:
b) An enhanced SelectProfile() in binfileimplclient.cpp, which would
check that flag and figure out which superdatastore to instantiate in
addition to the normal datastores
On Do, 2010-02-11 at 19:50 +, Patrick Ohly wrote:
[no target for superdatastore]
The only solution I see is to make the subdatastore URI's more complex:
instead of foo, let's use foo:uri where foo is the name of the
superdatastore and uri its remote URI.
I'm going with that and have syncs
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
(SUPERDS_VIRTUAL) and TSuperDataStore does not
have a derived implementation for it (yet).
I got it working without such a change. Of course, working and
working nicely/as intended are possibly different. Let me know if
you'd like to see it implemented differently.
--
Best Regards, Patrick Ohly
.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
session state)));
}
The only implementation of canBufferRetryAnswer() that I find returns
false, so we end up in the else branch and indeed, in some cases the
state gets messed up.
I'll keep looking into how I can enable this. Hints welcome.
--
Best Regards, Patrick Ohly
The content
On Fri, 2010-02-26 at 06:51 +, Patrick Ohly wrote:
The only implementation of canBufferRetryAnswer() that I find returns
false, so we end up in the else branch and indeed, in some cases the
state gets messed up.
I'll keep looking into how I can enable this. Hints welcome.
I've got
. I found two problems (see other emails), but none that I
could attribute to SyncEvolution ;-}
In which situation on the server side is the distinction between
lastToken and resumeToken relevant?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I
side are set via a key in the
profile that corresponds to the data source. I'm sure this is in the
documentation somewhere. Here's how we do it in SyncEvolution:
http://git.moblin.org/cgit.cgi/syncevolution/tree/src/syncevo/SyncContext.cpp?id=syncevolution-0-9-2#n1646
--
Best Regards, Patrick Ohly
On Fri, 2010-02-26 at 15:05 +, Patrick Ohly wrote:
[...]
So it seems that the engine does check for the remote ID, but only after
having already added the item again.
I think this was due to not enabling resumesupport. After setting
that, the same test passes. Sorry for the confusion - I
On Thu, 2010-03-04 at 23:49 +, Lukas Zeller wrote:
On Mar 4, 2010, at 18:49 , Patrick Ohly wrote:
On Fri, 2010-02-26 at 15:05 +, Patrick Ohly wrote:
However, while tracking through the code I found that indeed in the
server, the case of a client sending duplicate Adds
as local,
just as if they came out of the engine.
Client and server don't agree on whether the session should continue
(steps 8 and 9). Not sure who is right here.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel
/MetaData...)
9. server attempts to parse the item, fails and returns 415
The logs don't tell me what the relevant difference is, so I'll have to
dive into the debugger.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel
, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
will convert from one
format into another. The format is defined by a datatype in the XML
configuration. The aa:bbCRLF format is not such a datatype.
Can you describe what you are trying to accomplish? Perhaps there are
other ways to do it, or it is useful enough to add something.
--
Best Regards, Patrick
to/from the field
list (SyncSource.cpp)
* in your AsKey() implementations, read/write the data field
(SyncSourceSerialize::readItemAsKey,
SyncSourceSerialize::insertItemAsKey)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only
On So, 2010-03-07 at 01:56 +0100, Patrick Ohly wrote:
Anyway, it fails in one case when the item was split:
1. client has a new big item
2. client sends Add with MoreData/
3. server buffers the item
4. client sends second half
5. server processes the complete item
On Fr, 2010-02-26 at 15:12 +, Patrick Ohly wrote:
Hello!
When we started with SyncEvolution, we discussed the StartDataRead()
resumeToken parameter. At that time, we came to the conclusion that a
binfile based client doesn't have to distinguish between different
tokens. Always reporting
client? Is it possible in a
server?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel
On Thu, 2010-03-18 at 14:05 +, Lukas Zeller wrote:
Hello Patrick,
On Mar 18, 2010, at 14:00 , Patrick Ohly wrote:
On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote:
Most probably, there should be an extra check for that too late
suspend.
Your patch in the luz branch works
to it would break server
software upgrades.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel
mimeprofile
which matches exactly what Evolution supports.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf
On Wed, 2010-04-07 at 13:45 +0100, Patrick Ohly wrote:
Hello!
This is related to http://bugzilla.moblin.org/show_bug.cgi?id=10462
[...]
I suppose for SyncEvolution 1.0 we should simply remove the extension
from the XML config used by us. There's a slight loss of functionality
when
the client really
provides a stable, globally unique UID and b) we would end up with only
one item even when both items were modified and thus should both be preserved.
- Don't store UID on the server. We want it there for backup/restore of
iCalendar 2.0 clients.
--
Best Regards, Patrick Ohly
On Mon, 2010-05-10 at 16:48 +0100, Lukas Zeller wrote:
Hi Patrick,
On May 10, 2010, at 9:04 , Patrick Ohly wrote:
Confirmed, works for me.
Thanks!
I should have mentioned that I had already made similar changes as you
on the moblin.org master branch (check for NULL obj in debug
the changes soon together with the other pending changes on my
branch.
Note that I updated master and doxygen once more today. Please pull
again before merging.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel
choose to support the initial
n rules, but not some specific ones. I assume the ordering of rules is
chosen so that there's never a need to not support, say rule #1 but
support rules #2 and #3?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I
of ReadNextItem:allfields? What effect
does it have when the plugin refuses to acknowledge that rule?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I
, then I'll punt the problem to you.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
one or the other
interpretation? Or perhaps it was part of meeting minutes?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I
with some specific fixes
backported, and then combine the libsynthesis update with some other
non-backward compatible changes in SyncEvolution itself.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here
15:40:44.964] Deleted command 'Status' (outgoing MsgID=0, CmdID=0)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized
On Do, 2010-11-11 at 14:52 +, Patrick Ohly wrote:
Hello!
I have a question about matching items. Here's my situation:
* Client and server both have the same iCalendar 2.0 VEVENT (UID
is identical).
* SUMMARY is changed on server, one line is added to description
On Mo, 2010-11-15 at 16:50 +, Patrick Ohly wrote:
Now that I had that sorted out, I was running into another configuration
issue: slowsyncstrategyduplicate/slowsyncstrategy is set in the
syncserv_sample_config.xml and SyncEvolution copied that. Therefore the
engine ended up trying
Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
From
On Mi, 2010-12-08 at 12:22 +0100, Patrick Ohly wrote:
I'm currently (involuntarily ;-) stress-testing this code by running
SyncEvolution-SyncEvolution syncs with lots of iCalendar 2.0 items,
which happen to have very long IDs.
Related to this: is there some way to increase the maximum ID size
(). Is that the
right solution or do I need to search for the reason why the mapping has
gaps?
Also note that I end up with a temporary ID which must have been used
before in an older sync session. Could that be a problem?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only
missing entries. I'll keep watching :-/
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel
UpdateMapItem( CContext aContext, cMapID mID );
So, what is the solution to this problem? Do I still misunderstand
something or is there a genuine problem? ;-/
FWIW, there was one DeleteMapItem for item SERVER in the sessions above,
but it was for ident 1 (after deleting it).
--
Best Regards
Patrick
and suitable for merging back?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter
as fallback might be a bit tricky, but I think the start time of
the event should do.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I
).
Merged into the meego.gitorious.org repo.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel
On Di, 2010-12-14 at 11:43 +, Lukas Zeller wrote:
Hello Patrick,
On Dec 13, 2010, at 13:22 , Patrick Ohly wrote:
From http://bugs.meego.com/show_bug.cgi?id=11241. Problem summary below,
patch attached. I'm a bit unsure about hard-coding UTC as time context
in that code, please
On Do, 2010-12-16 at 17:35 +, Lukas Zeller wrote:
Hello Patrick,
On Dec 9, 2010, at 17:47 , Patrick Ohly wrote:
I might have found it.
Scenario:
- SERVER is the ID on the server, CLIENT on the client
- server has a mapping from SERVER to #35 (ident 2) and to CLIENT (ident 1
On Fr, 2010-12-17 at 14:08 +, Lukas Zeller wrote:
On Dec 17, 2010, at 8:47 , Patrick Ohly wrote:
Now it turns out that there's a bad bug here, which probably explains
all this (and maybe other) weird behaviour.
I'm glad that you got to the bottom of this. Much better than pampering
On Mi, 2011-06-15 at 14:02 +0200, Patrick Ohly wrote:
Hello!
One of the problems that we have in SyncEvolution is the loss of
properties not supported by SyncML servers, like Google:
https://bugs.meego.com/show_bug.cgi?id=15029
For example, BDAY is not supported and gets lost in a round
I want the
default behavior. Does this look right?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf
previously?
So that doesn't seem to be it.
I'm now looking at the actual parser code... gdb to the rescue.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position
On Mo, 2011-06-20 at 17:27 +0100, Patrick Ohly wrote:
Problem solved...
Except for one field:
!-- store extensions that don't match any of the other fields --
field name=XPROPS array=yes type=string compare=never/
Profile:
property name=X-* suppressempty=yes show=false
On Mo, 2011-06-20 at 20:20 +0100, Patrick Ohly wrote:
Verified with debugging output. I've not looked into setfieldoptions()
for the exact logic which enables the field.
This has the effect that my X-FOOBAR-EXTENSION and X-TEST extensions
(stored locally in XPROPS) are not getting preserved
On Do, 2011-07-21 at 12:21 +0200, Patrick Ohly wrote:
Now there is only one other problem with PHOTO uris. They get encoded as
binary data:
PHOTO;VALUE=uri:http://example.com/photo.jpg
=
PHOTO;ENCODING=B;VALUE=uri:aHR0cDovL2V4YW1wbGUuY29tL3Bob3RvLmpwZw==
Is that because PHOTO is defined
be
attached to contacts in Evolution Data Server.
However, I'd like to mention in this context that the engine for a
long time contains a mechanism for the general problem with large
fields.
I know, but it didn't seem usable here, as you said.
--
Best Regards, Patrick Ohly
The content
to the
conclusion that a backend can return errors in the range 500 to the
Synthesis engine. That's what SyncEvolution is doing here.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent
On Di, 2011-08-02 at 15:39 +0200, Lukas Zeller wrote:
Hello Patrick,
On Aug 1, 2011, at 20:39 , Patrick Ohly wrote:
In a local slow sync between Evolution and Google Calendar I see the
following problem:
[...]
* The server logs Status: 403: originator exception
On Tue, 2011-10-25 at 09:24 +0200, Lukas Zeller wrote:
Hello Patrick,
On Oct 24, 2011, at 16:55 , Patrick Ohly wrote:
Why is it necessary to read before trying to delete? If the item exists,
then reading it is a fairly expensive test.
Unfortunately, with some some backends
On Tue, 2011-10-25 at 09:24 +0200, Lukas Zeller wrote:
On Oct 24, 2011, at 16:55 , Patrick Ohly wrote:
Why is it necessary to read before trying to delete? If the item exists,
then reading it is a fairly expensive test.
Unfortunately, with some some backends, this is the only test
On Mon, 2012-01-30 at 18:04 +0100, Patrick Ohly wrote:
Should it have removed one item while processing the Map?
IMHO it can't, because it doesn't have enough information to determine
which of its two items are up-to-date. It only knows that the client
must have merged two items, but not yet
On Tue, 2012-02-07 at 16:05 +0100, Patrick Ohly wrote:
On Mon, 2012-02-06 at 21:29 +0100, Patrick Ohly wrote:
I'm currently experimenting with a different approach for handling the
409 in the binfile client: when an Add fails with 409, catch it as it is
done at the moment, but then tell
On Tue, 2012-03-06 at 14:50 +0100, Patrick Ohly wrote:
I haven't look into this yet, but still have it on my radar.
Done in the meego.gitorious.org master branch. I found that checking for
collisions is hard (not all records are in memory), so I settled for
making the chance of collisions
in
Python using the Twisted framework and depends on the D-Bus API provided
by the SyncEvolution core, so one also inherits all the rest of
SyncEvolution (own configuration system, backends, etc.).
For writing one's own server, the Synthesis SDK and server will be
easier.
--
Best Regards, Patrick Ohly
wasn't sure anyway
whether I would get the pointer to the local or remote datastore.
Any hints?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position
On Fri, 2012-04-27 at 16:27 +0200, Lukas Zeller wrote:
On Apr 25, 2012, at 15:11 , Patrick Ohly wrote:
But in practice that pointer is always NULL. I wasn't sure anyway
whether I would get the pointer to the local or remote datastore.
from fDsP you'd get the pointer to the local datastore
. Some of reporting inside
libsynthesis duplicates my own reporting. So I'd rather disable console
printing dynamically and only enable it when the log level in
SyncEvolution is sufficiently high.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am
small the message size should
be.
I don't know. I guess you could try asking Funambol (their mailing list
is now on SourceForge), but be prepared to be told to install a Funambol
client and emulate its behavior (that was the response that I got for
the DevInf issue).
--
Best Regards, Patrick Ohly
1 - 100 of 144 matches
Mail list logo
