Hi Fabio,
Fabio Forno wrote:
On Feb 4, 2008 9:52 PM, Joonas Govenius <[EMAIL PROTECTED]> wrote:
The problem is that you need to create a "record" for each new DOM node
that is added to the document. Therefore, if we want an instruction that
adds its XML payload to the document, we need to specify a unique way of
implicitly generating a record for each node in the payload. However,
that seems error prone especially given that different DOM engines may
parse the XML payload differently (e.g. I think IE ignores some
whitespace nodes that Firefox doesn't).
Uhm, I don't think it's absolutely necessary. For example you could
select the node where to apply changes using an xpath query, e.g.: add
this node to /root/child1/[EMAIL PROTECTED]"spam"].
The xpath method can't handle two different people appending child nodes
simultaneously; they would end up in opposite orders on the two clients'
copies.
Moreover the
particular application could already provide explicit ids for nodes,
and the transport could use them.
I don't think we want to make the transport rely on a particular
application.
In fact, as it is right now, the SXE implementation of psi for example
exposes only a regular DOM document to the application (whiteboarding),
except that the application has to use methods like
SxeSession::setAttribute(DomNode node, char* name, char* value) instead
of node.setAttribute(char* name, char* value) to modify the document.
The application implementation doesn't need to know anything else about
the transport.
Basically what I'm saying is that
the application could decide to switch to a different transport if it
is more efficient and supported by both clients, but I think that
jingle will help a lot in this. Perhaps the protocol won't need
changes, just examples showing how to do the negotiation.
Agreed. I suppose those examples would belong in the XEPs that define
application types.
Joonas
