incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary “Gamer_Z.” Yaro <>
Subject Re: Wave Extensions Gallery integration
Date Wed, 01 May 2013 00:03:23 GMT
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?

I fixed the issue with the Access-Control-Allow-Origin header.  I should
have caught that sooner, but I forgot Chrome extensions can do cross-origin
XHRs without the site explicitly allowing it.

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.

—Zachary “Gamer_Z.” Yaro

On 30 April 2013 05:49, Ali Lown <> wrote:

> A few quick changes to the client code, so that it fetches the data
> from your server directly results in a CORS violation. You don't
> appear to have set your 'Access-Control-Allow-Origin' header?
> 'XMLHttpRequest cannot load
> Origin
> http://localhost:9898 is not allowed by Access-Control-Allow-Origin.'
> By having the client directly fetch the gadget data from the gallery
> it is always up-to-date, and is only as slow as a single network
> connection, but has the disadvantage of possibly being worse for your
> bandwidth bills. :P
> The alternative would be to have the server fetch the list and
> maintain its own local copy, so that the client then requests the
> gadgets from the wave server (as it does currently). What do we want
> to do about searches in this situation though? Direct from the
> gallery, or proxied via the local wave server? (How does this work
> when federation is in action?). This also has issues with the gadget
> list being 'out-of-date'. And in the event it acts as a caching proxy
> could make using the gadget browser quite slow since it would be
> dependent on 2 network links...
> Thoughts?
> Ali
> On 30 April 2013 08:32, Ali Lown <> wrote:
> > Zachary,
> >
> > I will take a look at implemeting this today.
> >
> > Based on a cursory glance. It looks like it would be useful to be able to
> > pass a 'type' to the search request so that it returned only gadgets or
> > robots, but not a mix of both, which is what it sounds like it would do
> > currently.
> >
> > Ali
> >
> > On 30 Apr 2013 04:59, "Zachary “Gamer_Z.” Yaro" <>
> wrote:
> >>
> >> A little over a month ago, I announced the first release of the Wave
> >> Extensions Gallery search
> >> API<>.
> >>  Not long after that, I released the WEG Loader for
> >>
> >> Rizzoma<
> >
> >> Chrome
> >> extension, which used the WEG search API to put WEG gadgets in Rizzoma's
> >> gadgets menu.  It would be great to see WEG gadgets also be searchable
> >> from
> >> the WIAB gadgets dialog.
> >>
> >> WIAB already has a gadget searching UI.  It would require essentially no
> >> UI
> >> changes to implement this.  All that would change is what happens with
> the
> >> search query behind the scenes.  Instead of searching within a
> hard-coded
> >> JSON file, send a request to the WEG search API and parse the JSON
> >> response.
> >>
> >> The advantages of using the WEG API over the current method are a) the
> >> gadget URLs, icons, and metadata will always be up-to-date, and b) WIAB
> >> instances will not all need to store their own hard-coded gadget lists.
> >>
> >> Unfortunately, I am not proficient enough with GWT or familiar enough
> with
> >> the WIAB client to implement this myself.  Are any WIAB developers able
> >> and
> >> willing to attempt this?  Feel free to contact me with any ways I can
> >> modify the WEG or its APIs to make this easier for you.
> >>
> >> —Zachary “Gamer_Z.” Yaro
> >>
> >> P.S. I also added an entry for this feature request in the Apache Wave
> >> JIRA<>
> >> .

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message