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+t...@todo</DisplayName> ... <DataStore> <SourceRef>./Calendar</SourceRef> <DisplayName>calendar+t...@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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
