Alex can you please describe the differences between the wave ids as they are in Google Wave/Sandbox instances and the draft spec? Let' us not forget that Sandbox instance is federated and has some data. Also, i couldn't understand from the spec how blip (document) ids are represented. In Google Wave each blip has it's own id like: googlewave.com/w+ihNkzrFlA/~/conv+root/b+LWFcI7ZkBH9. I am currently working on links edit/rendering and speaking in this context it seems like currently wiab doesn't allow to implement up to blip level links.
On Dec 17, 5:05 am, 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. > > -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%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 at http://groups.google.com/group/wave-protocol?hl=en.
