I can't see how that would work. I think the only way would be to apply a single "upgrade" delta. But of course, that means that if you try to play back the history, revisions before that upgrade wouldn't be viewable. It's a tricky problem.
On Thu, Feb 4, 2010 at 12:13, Torben Weis <[email protected]> wrote: > 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%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%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]. >> >> > 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]. >> > 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]. >> 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. > -- 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]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
