So I don't think I actually convinced many people of the value of change here, but neither were there any outcries about anything that might actually break.
I've been making numerous improvements to the use of ids inside WIAB, and if you've been following the patches this might have been educational. But I'm now up to the point of changing the format of the data that goes on disk and over the wire. I'm willing to do this work. For the robot protocol I definitely agree with Tad that we should keep interoperating with robots using the old serialisation. I propose that we continue serialising to the same format as robots currently expect, but restrict ids to those conforming to the new specification. The transport serialisation can then change to the URI form later. Since WIAB doesn't yet persist data, robots interacting with WAIB can't have any stored data that will be made invalid. For federated deltas, and the data embedded in those deltas (like in the conversation model and user-data wavelet) I also propose to both restrict valid identifiers to the charsets in the draft spec and serialise them in the straightfoward draft-spec way rather than the undocumented and awkward current method. In this case I don't think there is a compatibility option; the serialised ids are part of the signed delta. Again, however, WIAB doesn't persist data and no-one shouted out with things that will break (wavesandbox is a sandbox and not maintained, demo.waveinabox.org is a better integration test) - I think now is the time to make this simplification. Please let me know if you disagree so we can figure out a way forward. Alex On 20 December 2010 14:32, Alex North <[email protected]> wrote: > On 20 December 2010 13:47, Tad Glines <[email protected]> wrote: > >> On Sun, Dec 19, 2010 at 3:14 PM, Alex North <[email protected]> wrote: >> >>> On 17 December 2010 14:05, Tad Glines <[email protected]> wrote: >>> >>>> I think this transition would be easier if there was a defined >>>> translation to/from the old/new ids. Then WiaB could store/use new ids, but >>>> be able to support APIs that need to use the old ids. >>> >>> >>> There's two different things going here. One is translating between id >>> serializations to talk to older APIs. I definitely agree and will implement >>> that. >>> >>> The second is dealing with existing data that uses ids containing >>> characters that are not valid in the new spec (e.g. '/' inside a token). >>> Because WIAB has not had persistence, there is no existing data there. It's >>> easy to define a one-way mapping so that for importing data from Google Wave >>> or other systems, WIAB can find a new id for broken ones (and update all >>> references to it on the way). But a two-way mapping is going to be harder. I >>> don't think it's worthwhile unless someone screams out that making ids >>> containing '/' invalid (or anything else in the draft spec) is going to >>> break them. >>> >> >> Why not just URI encode (or similar) the bits that are not allowed in the >> new spec? >> > > The new spec is explicitly constructed to have wave links (URI forms of > wave ids) not be full of ugly encoding. If characters in tokens making up an > id are %-encoded already then they get double %-encoded when the id is > expressed as a URI. % is a disallowed character for this reason. Some other > encoding would be possible, sure, but hella ugly. I think it would be > complex to identify when this encoding would be necessary; modern systems > interoperating would never need it. > > > >> Since there is no defined translation from old to new, why not define a >> translation that ensure that illegal characters in the old spec get >> translated (in a reversible way) a set of legal characters in the new spec. >> > > I agree that such a translation is possible in principle, but I believe it > will be complex. The only case where I can actually see it being useful is > for federated systems with existing data. These will be thwarted by > signatures anyway. And I don't know of any that will actually have a problem > (ids that aren't automatically valid are unlikely). > > >> >> -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]> >> . >> 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 at http://groups.google.com/group/wave-protocol?hl=en.
