WQLite                                      WQL

---------                                    -----------

foo                                           {"match":"foo"}

type:Ticket foo                          {"type":"Ticket", "match":"foo"}

name:Bug_1                             {"name":"Bug 1" }

->JohnAbbe                              {"refer_to":"JohnAbbe"}

type:Ticket +status:open           {"type":"Ticket", "right_plus":["status",{"content":"open"}}

type:Ticket +tags->Wagn_1.0    {"type":"Ticket","right_plus":["tags",{"refer_to":"Wagn 1.0"}]}

 

 

which would YOU rather write?  ;-)

 

• degrades to normal search syntax, so we can use it search boxes all over
• much easier to implement than GUI  (imho)
• more streamlined than GUI for power users

---

note: I don't see this as replacing WQL- it wouldn't be able to cover the depth and nuance; but it could make a lot of the commons cases much more palatable for users who'd be on the edge of using it.

  --Lewis Hoffman.....Sat Sep 27 21:08:29 -0700 2008

---

I'm with you on the general idea of there being a WQLite, though I think the name is misleading. It's not a separate implementation like SQLite, it's just a shorthand notation (like...selenese?). WQL, to me, is already an abstract object representation -- neither the ruby nor the JSON is the "real" version. I don't have a great alternative yet, but maybe something like Quikwuk, Wukwuk, or WQLhandy.

I have bigger problems with particulars of the suggestions above.

 

Eg, , in wql, "foo" means the card named "foo". if "foo" means any card matching foo (as you said above), then wouldn't "->foo" mean any card pointing to any card matching foo?

That one's easy. ~foo should = {:match=>'foo'}  The more conceptual issues come with (a) the use of unreserved characters (which we could resolve by forcing it to use only alpha numerics in the card names, resolving them always to keys), and (b) the lack of exploration of more complex cases, which I suspect will still need to involve {}'s and []'s or some alternative (such as significant whitespace).

 

Unless the shorthand can do it all, I wouldn't really want to code it up.

Then there are some other big questions about what this would mean in terms of interface. Would we initially just get rid of the JSON interface?

  --Ethan McCutchen.....Mon Sep 29 09:57:09 -0700 2008

---

imo, this is going to be pretty low ROI (way way lower than the pattern stuff). There are no new possibilities it opens up, and the number of users that will use this but not the other, I imagine, are tiny. So long as it's an object notation, not a GUI, only real power users will use it at all ever, and they would have to be super power users to be writing it often. How often do you write it?

I feel like investing time in this as compared with the GUI is hard to justify in the short run, though I do eventually want it, even if just for a pretty narrow audience (which includes me). The next step would be a lot more design.

  --Ethan McCutchen.....Mon Sep 29 11:28:47 -0700 2008

---

I like it.

If we go down this road we imho end up either: maintaining two separate syntaxes, or shifting entirely to a pithier one that has the same power. I'd be arguing in favor of the latter if we go this way. It's a good question to ask Wagneers as we go along, whether they'd prefer our coding resources to go first into a better syntax or a GUI for searches (though i imagine

Tangentially, i think the analogous thing for the GUI (not full-power of current WQL) is the 'full' search interface that allows more than the search(/goto) box.

  --John Abbe.....Mon Sep 29 14:35:45 -0700 2008