2010/2/4 Anthony Baxter <[email protected]> > How would upgrading the schema of an existing document work with > signed deltas? Would the server construct a new delta for the schema > upgrade, and sign it as itself? > > In general, is it allowed for a server to sign deltas on behalf of remote users?
By accident my wave server (let's call it wave1) signed a delta submitted by a remote user "t...@wave2". When I sent this wavelet update to FedOne it complained that the certificate of wave1 (which signed the delta) does not include the domain wave2 (which submitted the delta according to the author attribute). I concluded that the wave server of the delta author must always sign. Thus, is there a legitimate way for a server to modify deltas submitted by others and sign them afterwards? Torben > On Thu, Feb 4, 2010 at 11:30, Daniel Paull <[email protected]> wrote: > > Simple solution, yes. But it sure sucks to be stuck on an old schema > > if the new schema was developed to support new features that you want > > to use... Perhaps a not-so-simple solution should be thought through. > > > >> just as you don't change the schema of an XML document once it has been > created > > > > eh? I've seen OpenOffice upgrade my documents form an old schema to a > > new one and they're XML docs, right? I expect Microsoft does the same > > thing with their fancy new XML formats too. > > > > Dan > > > > On Feb 4, 3:38 am, Tad Glines <[email protected]> wrote: > >> The simplest solution is to not allow changing the schema once the > >> wave is created, just as you don't change the schema of an XML > >> document once it has been created. > >> > >> -Tad > >> > >> > >> > >> On Tue, Feb 2, 2010 at 11:32 PM, Daniel Paull <[email protected]> > wrote: > >> > If we start talking about versions of shemas, then we are going to > >> > have to talk about clients that persist waves and allow offline work. > >> > Imagine that schema 1 is used to create a wave and a user takes the > >> > wave offline to do some work. The server is then upgraded to schema > >> > version 2. The user then reconnects to the server, expecting to > >> > commit their offline work. How do you merge in operations performed > >> > against the old schema version? It would be really bad form to not > >> > accept the changes as the changes may represent a lot of work. > >> > >> > Cheers, > >> > >> > Dan > >> > >> > On Feb 3, 6:36 am, Tad Glines <[email protected]> wrote: > >> >> Some level of schema/structural checking will be required in order to > >> >> prevent malicious users from corrupting waves (or crashing the > server). If > >> >> the server does nothing with the content other than ensure that the > >> >> operations are legal (WRT basic wave OT), then no schema checking > would be > >> >> required at the server level. But if the server has to do something > with the > >> >> content (e.g. content transormation) then some level of structural > >> >> constraint would need to be enforced by the server. We've already > seen cases > >> >> where improper ordering of operations crashes a wave on wavesandbox. > So some > >> >> level of structural constrain is needed. > >> > >> >> In the case where there are multiple client implementations and > multiple > >> >> conversation model versions (it'll happen) there will need to be some > means > >> >> of communicating to clients and server what model is in use for a > wave. It > >> >> could be as simple as a "model_version" attribute in the root > "conversation" > >> >> element. Or it could be as complex as a special wavelet in the wave > that > >> >> defines the schema to namespace mapping in force for that wave and > it's > >> >> wavelets. Something other than "everybody play nice together" will be > >> >> needed. > >> > >> >> -Tad > >> > >> >> On Tue, Feb 2, 2010 at 1:45 PM, Torben Weis <[email protected]> > wrote: > >> >> > Hi Tad, > >> > >> >> > I definitely see a demand for supporting new document types. > However, > >> >> > enforcing them upon each submit-request can cause significant > computation > >> >> > overhead on the server. The other options I could imagine: > >> > >> >> > a) Keep it as it is: The server cares for well-formedness an the > client has > >> >> > to deal with the documents one way or the other > >> >> > b) Option a) plus lazy evaluation. Every client can indicate the > server > >> >> > that a document is broken and the server checks & rolls back. > >> > >> >> > Your proposals are technically cleaner, but I am really worried > about > >> >> > performance ... > >> > >> >> > Cheers > >> >> > Torben > >> > >> >> > 2010/2/2 Tad Glines <[email protected]> > >> > >> >> >> Interoperability requires that clients and servers agree on the > wave > >> >> >> content structure (schema). There is work in process for the > conversation > >> >> >> model, but there is no general mdoel for how a client or server > can describe > >> >> >> the allowed schema of a wave it creates. In XML this is already > solved. And, > >> >> >> while wave documents are not XML, they allow a similar structure. > It would > >> >> >> seem to me that a very useful addition to wave would be the > ability specify > >> >> >> and determine the schema associated with a wave/wavelet/document. > >> > >> >> >> There is already some model code that supports this > (DocumentSchema and > >> >> >> BootstrapDocument), but there is no way for a server to know which > schema, > >> >> >> if any, should be enforced. There seems to be two possible ways to > handle > >> >> >> this. One is to associate a schema with a particular namespace > prefix. So, > >> >> >> for example, documents with names starting with "b+" would have to > conform > >> >> >> to the blip schema and documents with the name "conversation" > would be > >> >> >> required to conform the conversation schema and blips references > therein > >> >> >> would have to conform to the blip schema. An alternative would be > to add > >> >> >> some means to specify a schema for a wave/wavelet/document upon > creation or > >> >> >> later during modification. In the later case, there would need to > be a > >> >> >> mechanism for specifying the schema to use, either by well known > name, of by > >> >> >> including the actual specification. > >> > >> >> >> The schema to namespace mapping seems the easiest to implement but > the > >> >> >> other method provides more possible flexibility at the expense of > additional > >> >> >> complexity and possible conflict resolution issues. > >> > >> >> >> Has Google, or anyone else considered this matter? > >> > >> >> >> -tad > >> > >> >> >> -- > >> >> >> You received this message because you are subscribed to the Google > Groups > >> >> >> "Wave Protocol" group. > >> >> >> To post to this group, send email to > [email protected]. > >> >> >> To unsubscribe from this group, send email to > >> >> >> [email protected]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > >> >> >> . > >> >> >> For more options, visit this group at > >> >> >>http://groups.google.com/group/wave-protocol?hl=en. > >> > >> >> > -- > >> >> > --------------------------- > >> >> > Prof. Torben Weis > >> >> > Universitaet Duisburg-Essen > >> >> > [email protected] > >> > >> >> > -- > >> >> > You received this message because you are subscribed to the Google > Groups > >> >> > "Wave Protocol" group. > >> >> > To post to this group, send email to > [email protected]. > >> >> > To unsubscribe from this group, send email to > >> >> > [email protected]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > >> >> > . > >> >> > For more options, visit this group at > >> >> >http://groups.google.com/group/wave-protocol?hl=en. > >> > >> > -- > >> > You received this message because you are subscribed to the Google > Groups "Wave Protocol" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > >> > For more options, visit this group athttp:// > groups.google.com/group/wave-protocol?hl=en. > > > > -- > > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > > > > > > -- > Anthony Baxter, [email protected] > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
