I cannot agree more. Even if the common usage of waves until now has been of many small blips, there are waves consisting of long small blips, in which case, a link to different places inside a blip is needed. I have little idea about the internals, so I may use wrong concepts naming, but I think something like "blip/wave version" + "character count" would be needed. This way, you can link anywhere inside a blip (e.g. "right click" -> "link to this exact place in blip"), and then "place" will get the appropriate OTs applied if the blip changes (from the linked blip/wave version up to latest blip/wave version). So that it keeps pointing to the same place as the original link author intended.
On Sat, Dec 18, 2010 at 12:59, Yuri Z. (a.k.a Vega) <[email protected]> wrote: > To state it more clearly, the current smallest wave entity is blip, > however it's too coarse grained. The smallest wave entity should be > "anchor". So every blipUi has at least one anchor to the document > start. > > On Dec 18, 1:48 pm, "Yuri Z. (a.k.a Vega)" <[email protected]> wrote: >> 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. > > -- Saludos, Bruno González _______________________________________________ Jabber: stenyak AT gmail.com http://www.stenyak.com -- 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.
