ah, ok, thanks for clarifying. Yes, I pictured the tags as effectively being used to define topic(s) that a wave represented, and hopefully being treated much like gmail's labels. (filters, cross-references possible, and maybe even auto- applying certain ones based on specific criteria)
On Dec 7, 5:13 am, Alex North <[email protected]> wrote: > Ah, I should have been a bit more clear about what this proposal is for. > > This design specifies a transport for search results (and queries, but it > proposes just a normal RPC). Search results are a list of waves, probably > with some per-user data like whether they've read the wave before. It's a > means of communicating these results from the server to the client. It does > not specify: > - the internal storage representation for any indexing infrastructure (i.e. > how to answer the question "what's in my inbox") > - what can be searched for, the language for search queries, etc > > I'm not convinced that managing actual indexes in wavelets is a good idea, > but it's outside the scope of this proposal. The current inbox > implementation confuses both the raw index information with the > communication to a client, and I think this was a short-sighted decision. > > This design doesn't cover how to search for waves, just how to communicate a > query and results assuming some search infrastructure. Something like Google > Wave's tags (same as Thomas's topics?) would be very useful and is not hard > to implement. But it's a separate mechanism to this. > > A > > On 7 December 2010 11:56, ThomasWrobel <[email protected]> wrote: > > > > > > > > > This is a preposal for searching in waves for specific text strings > > and displaying the results as a wave right? It seems fine for that > > angle. > > > What about searching for a wave itself ? Has consideration been put > > into that in some way, so waves can be labeled for topics, then people > > can search for specific labels or combinations of labels. (presumably > > with those waves labeled the same by most people being considered > > stronger/more trustworthy). > > As far as public waves go, I think the initial "search" before a user > > subscribes is a problem in itself. > > > On Dec 6, 11:44 pm, Alex North <[email protected]> wrote: > > > Hey all, > > > > A few months ago Joseph and I worked on a design for using a wave as the > > > communication transport for search results, including your inbox. We then > > > decided that while this mechanism is good and wavey, Wave in a Box would > > be > > > better served by first taking advantage of the search Data API to get > > basic > > > inbox and search functionality without adding so much code. > > > > I'm publishing the design now just because it's come up in a few > > > conversations. I don't think we should implement it (or something like > > it) > > > yet, but perhaps some time next year after basic WIAB is up and > > functional. > > > >https://sites.google.com/a/waveprotocol.org/wave-protocol/protocol/de... > > > > A. > > > -- > > 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.
