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.
