Re: [SyncEvolution] Nokia N85 sync status
On Do, 2010-02-18 at 22:52 +0000, Lukas Zeller wrote:
Hello Patrick,
On Feb 18, 2010, at 17:53 , Patrick Ohly wrote:
> Speaking of confused, I'm a bit confused about CTCap inside DevInf right
> now. In the SyncEvolution client <-> SyncEvolution server scenario, the
> client sends DevInf including CTCap to the server in its first message.
> The server sends DevInf in its reply, but without any CTCap. I don't
> have <showctcapproperties> in my config.
>
> I would expect to see the server's CTCap in the session. Any idea why it
> is not sent?
The only reason I can think of right now would be a too small message
size, which the devInf exceeds. If that happens, CTCap is left out to
make the devInf sendable, because <results> can't be split across
messages.
That was exactly the reason. The WBXML message turned out to be only
slightly smaller than 64KB. SyncEvolution had a very small maximum
message size of 20000 bytes - I don't remember why we made it so small.
I've increased it to 150000 bytes. What are the maximum message sizes
used by the Synthesis clients?
The CTCap turned out to be that large because it includes all
datastores, even the sub-datastore that are only configured because they
are part of the superdatastore. Is there a possibility to prevent
inclusion of these stores in the DevInf?
I understand that a general-purpose HTTP server leaves the choice of the
store to the client, but in our case (phone over Bluetooth) we expect
the device to use exactly the stores that we have prepared for it.
Coming back to the N85, the DevInf sent to the device includes three
datastore entries:
<DataStore>
<SourceRef>./Calendar</SourceRef>
<DisplayName>calendar+todo@todo</DisplayName>
...
<DataStore>
<SourceRef>./Calendar</SourceRef>
<DisplayName>calendar+todo@calendar</DisplayName>
...
<DataStore>
<SourceRef>./Calendar</SourceRef>
<DisplayName>calendar+todo</DisplayName>
While stepping through the code I noticed that there is code which uses
the URI from the client's Alert - is that perhaps why the two
sub-datastores and the superdatastore use the same <SourceRef>?
At least it wastes some bandwidth. If we are unlucky, in confuses the
client.
I can imagine that including stores which have not been alerted yet
might be useful, in case that the client sends an <Alert> for one store
first and later for another one, but sending all stores with the same
URI as above doesn't make sense to me.
In the SyncEvolution as client case this doesn't happen because the
server's DevInf is created before the client's first Alert.
--
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.