Also, I think that full identifier should be of the form example.com/w +abc/~conv+root/b+1234/a+abcd where the last path section (/a+abcd) is a custom optional anchor, this is in order to allow to reference elements not only up to blip level, but also inside blips. The ability to uniquely reference elements inside blip is important for the search functionality. For example, if user searches for certain text in Google Wave - the search result is just a list of waves that contains the specified text. It there are 900 blips in the wave - it is of very little use to know that 1 of them contains text you need, you still need manually to go over the blips and look for the text. Even if the search would take directly to the blip that contains the text - it is still not good enough as blips can be very long. So it is obvious that the full id should be able to reference elements inside certain blip.
On Dec 17, 4:47 pm, Vega <[email protected]> wrote: > 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.
