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 the server. Right?
I missed one aspect of the spec (OMA DS Protocol 1.2.1, 12.2 Structure of the Server Alerted Sync Package): for each data source, the request by the server only contains a binary MIME type and the server URI. I thought that it would contain the device URI and the corresponding server URI. The server SHOULD set the MIME type, but this is not absolutely required. That of course simplifies the generation of a SAN package on the server, but it raises the question how the client can synchronize against the server without some additional configuration on the client. More specifically, when receiving a zero MIME type and URI "/foo", how does the client know what data the server is asking for? Even with MIME type "text/calendar" it is not obvious, because that can be both tasks and events. The only solution that I see is to hard-code some well-known server URIs in our code and to use local configuration, if it exists. Did I miss anything? One more question: the SAN header contains the server ID, just as in the DevInf. This is the only way how a client can identify the configuration which might have been prepared locally for that server. But when preparing that configuration the client doesn't know the server ID yet. Do I miss something here? How on earth is this supposed to be interoperable between software of different vendors? > How is the mapping from textual MIME types to the binary MIME type > numbers in the SAN handled? This looks like a serious limitation of the > SAN format to me, because what number should be used for experimental > MIME types which haven't been registered? Sending 0 is allowed. -- 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. _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
