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. A. > -Tad > > On Thu, Dec 16, 2010 at 4:14 PM, Alex North <[email protected]> wrote: > >> Wave identifiers as currently implemented (Wave[let]Id.java) do not >> conform to the draft specification we published at >> http://wave-protocol.googlecode.com/hg/spec/waveid/waveidspec.html. That >> spec limits code points valid inside an identifier with an explicit goal of >> supporting natural URI construction and wave references/links. >> >> The existing code is far too relaxed in allowing just about any character >> in an id, requiring lots of escaping wherever they are used and generally >> causing pain. The existing escaping scheme (WaveId.serialize()) is also a >> bit simplistic and doesn't help mattters (the results are still not >> URL-safe). >> >> We lagged in fixing this because the prospect of migrating existing Google >> Wave data was too daunting. Apache Wave is the perfect opportunity to fix >> some fundamental flaws here, before too much data is generated (yay for no >> persistence yet). >> >> I propose to change wave ids to implement the draft spec we published and >> clean out lots of serialization cruft. The biggest potential roadblock to >> this is that *if* a federated service generates ids that are incompatible >> with the spec, those ids will not be allowed by WIAB. Since there are no >> WIAB services that can persist data yet, I don't expect this to be many, but >> I'm aware some services may be creating and persisting data without using >> WIAB code. >> >> The change will also change things where ids are transported or persisted. >> Some examples: >> - user-data wavelet >> - wave links >> - URL bar history hash >> - c/s protocol >> - robot protocol >> >> The robot protocol is an interesting case, because changing the id >> serialisation to be a URI is backwards-incompatible. I hope we can move the >> robot client library forward to use the new form, but if developers desire >> it we may need to keep supporting the old serialisation just for that >> protocol for a while. >> >> Comments? Objections? >> >> -- >> 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]<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.
