Regarding the search with Data API - I think most of the code can be ported from the Splash project - which makes the Data API option even more feasible.
On Dec 7, 9:03 pm, ThomasWrobel <[email protected]> wrote: > 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 forsearchresults (and queries, but it > > proposes just a normal RPC).Searchresults 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 forsearchqueries, 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 tosearchfor waves, just how to communicate a > > query and results assuming somesearchinfrastructure. 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 > > > cansearchfor 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 forsearchresults, 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 thesearchData API to get > > > basic > > > > inbox andsearchfunctionality 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.
