> It is possible to search for only gadgets. Just append “type:gadget” to > the query. I will add a note to the documentation about advanced search > keywords. Is there a reason you see why that should be available as a URL > parameter as well, or is the method I listed above acceptable?
Ok. I don't think it makes any difference whether it is a search keyword or a URL parameter. I requested it because I didn't see any mention of any search keywords. > I see advantages to both options for how WIAB should handle the gadgets > list, but I think it is important for wave clients to be able to make API > calls directly since not every wave client will necessarily be as tightly > connected to a server as WIAB is. A pure client-side implementation can be found on my github currently: https://github.com/alown/wave/commit/0cdf070c52def0e711991ff1a5d2249703931751 This is a quick hack, as opposed to a tidy patch suitable for review, but you can see what I have done to make it work. A few notes: - The list api is _very_ slow, it seems to frequently take 10 seconds to fetch the list of gadgets, but the search api is 'instant' enough to not be a problem. (Why is this?) - The current gadget data includes primary and secondary categories. Can you make this information available over the api? (Assuming you have it?) - How should the up/down votes be presented in the UI? - Should I remove the bits of code related to the gadget json serving (since they would no longer be relevant?) - Adding any of the gadgets currently results in a 'Port error: Could not establish connection. Receiving end does not exist.' message from Chrome 27, but seems to work fine in Firefox 19.0.2. Ali
