Oh, wow, that was embarrassing. It should be fixed now.
—Zachary “Gamer_Z.” Yaro On 3 January 2013 04:05, Yuri Z <vega...@gmail.com> wrote: > http://wavygallery.appspot.com/api/v0/list.json?type=gadget causes an > error > > > On Thu, Jan 3, 2013 at 9:19 AM, Zachary “Gamer_Z.” Yaro <zmy...@gmail.com > >wrote: > > > I have been posting about updates on the Wave Extensions Gallery's > Google+ > > page <http://plus.google.com/111054500428067493902>, but it has been a > > while since this thread had any activity. If you visit the demo > > instance<http://wavygallery.appspot.com>, > > you can see a nice selection of gadgets have been imported from WIAB and > > are now searchable. > > > > While the UI could still use work, I want to get functionality in first, > so > > I have turned my attention to the API. Right now the experimental v0 > > API<http://wavygallery.appspot.com/docs/api> just > > allows for fetching of extension information as JSON. What other > features > > would the API need to be useful to developers of wave clients? I > obviously > > want to see the WEG succeed as a central database of wave extensions, > but I > > also want it to make wave developers' lives easier. > > > > > > —Zachary “Gamer_Z.” Yaro > > > > > > On 8 October 2012 18:51, Jérémy Naegel <jeremy....@gmail.com> wrote: > > > > > Some updates about the Wave Extensions Gallery: > > > > > > Yuri has created a demo server on AppEngine to make it easier to > > visualize > > > the app and help provide constructive feedback. > > > And Zachary has been working on a new UI for the landing page. > > > > > > You can check out the functional demo at > > > http://newui.wavygallery.appspot.com/ > > > > > > +Jérémy <https://plus.google.com/u/0/110860203879684078598> > > > > > > > > > > > > On Thu, Sep 27, 2012 at 8:41 PM, Zachary “Gamer_Z.” Yaro > > > <zmy...@gmail.com>wrote: > > > > > > > Responses inline below... > > > > > > > > —Zachary “Gamer_Z.” Yaro > > > > > > > > > > > > On Thu, Sep 27, 2012 at 2:48 AM, Bruno Gonzalez <sten...@gmail.com> > > > wrote: > > > > > > > > > Some questions... > > > > > > > > > > ("wave-extensions-gallery" abbreviated as "WEG" in this mail) > > > > > > > > > > - Each wave server would have its own accompanying WEG? (like a > > local > > > > apt > > > > > repository) > > > > > - Or is the idea to have a single, centralized, online WEG that > all > > > wave > > > > > servers would access? (a single official "google play" market, only > > for > > > > > gadgets/robots) > > > > > > > > > > > > > The latter. The idea was to create a WEG that could be accessed by > all > > > > wave servers (whether or not they were based on WiaB). > > > > > > > > > > > > > - Or each user can decide what WEGs to use by adding them to a > "WEGs > > > > list" > > > > > in their wave account preferences. And the wave server admin could > > > decide > > > > > to fill that list by default with certain WEGs (be it internal > and/or > > > > > external WEGs? (similar to /etc/apt/sources.list) > > > > > > > > > > > > > Since there is nothing stopping people from hosting their own WEGs > > (like > > > > the Amazon Appstore versus the Google Play Store), that could be an > > > option, > > > > but having many WEGs would defeat the purpose of the project. > > > > > > > > > > > > > - Or maybe a (internal) WEG can act as a cache for external > > > > > WEGs/robots/gadgets, to cover the case when those external WEGs go > > > > offline, > > > > > allowing people to still access their complete waves? (like a... > sort > > > of > > > > an > > > > > apt repository mirror/aggregator) > > > > > > > > > > > > > Wave servers are welcome to cache gadget files (I am not sure how > robot > > > > caching would work), but that is not really relevant to this project. > > > The > > > > goal here is to create a central place for extension data, but I do > not > > > > want to force developers into only one hosting option. > > > > > > > > > > > > > > > > > > Also, regarding gagets/robots: is it possible to "clone" any > external > > > > > gadget/robot without the cooperation of the authors (technically > > > > speaking, > > > > > and leaving politic issues aside). I guess this would be necessary > if > > > > WEGs > > > > > are to act as transparent caches. > > > > > I.e. just fetching an xml file is enough to completely clone a > > > > > gadget/robot and gain independence from the original? > > > > > Or is it needed to provide an specific system for developers to > > submit > > > > > gadgets/robots? > > > > > > > > > > > > > Many gadgets are self-contained, but I think some do link to outside > > > > resources. The self-contained ones could be copied just by getting a > > > copy > > > > of the gadget XML (though obviously there are legal and moral > > concerns). > > > > Given that robots are server-side, I do not think there would be any > > way > > > > to access a robot's code unless the developer chose to release it. > > > > > > > > > > > > > > > > > > On Thu, Sep 27, 2012 at 5:22 AM, Zachary “Gamer_Z.” Yaro > > > > > <zmy...@gmail.com>wrote: > > > > > > > > > > > (Re: Most gadgets broken are over SSL; split into a separate > thread > > > > > because > > > > > > I have a feeling this will end up off-topic.) > > > > > > > > > > > > I may have a potential solution to some of these problems. A few > > > > months > > > > > > ago, when WiaB first started including a hard-coded list of > > gadgets, > > > it > > > > > > occurred to me that problems might arise from that. To solve > > that, I > > > > > > started a project that I finally got around to coding about a > month > > > > ago: > > > > > a > > > > > > wave extensions gallery. > > > > > > > > > > > > The idea is to have a place, comparable to the Google Play Store > or > > > > > Chrome > > > > > > Web Store, where developers can add extensions (currently devs > must > > > > host > > > > > > their own extensions, but eventually I would like to set it up so > > > devs > > > > > can > > > > > > upload gadget XML to be hosted in the gallery) and users can > browse > > > > them. > > > > > > > > > > > > In addition, the gallery will include an API (currently this is > > very > > > > > > limited, but it will eventually include more features) so a WiaB > > > client > > > > > (or > > > > > > any other wave client) can fetch a list of gadgets that is always > > > > > > up-to-date. Eventually, I would like the API to allow wave > clients > > to > > > > > > access users' lists of favorite extensions. > > > > > > > > > > > > Currently the code (which, I admit, really needs to be cleaned > up) > > is > > > > > > available on GitHub < > > > http://github.com/zmyaro/wave-extensions-gallery> > > > > < > > > > > > github.com/zmyaro/wave-extensions-gallery>, and Yuri has set up > a > > > demo > > > > > > instance at wavygallery.appspot.com. > > > > > > > > > > > > This is still very early in development, but I want to get > feedback > > > > from > > > > > > others. What features should be added/changed. How can this > > project > > > > > > better help wave/WiaB/Walkaround development? Any suggested > > > > improvements > > > > > > to the app's structure? I would like to hold off on code > > > contributions > > > > > for > > > > > > the moment, but comments/suggestions/criticisms/etc. are more > than > > > > > welcome. > > > > > > > > > > > > —Zachary “Gamer_Z.” Yaro > > > > > > > > > > > > > > > > > > On Thu, Sep 20, 2012 at 5:29 AM, Ali Lown <a.lo...@gmail.com> > > wrote: > > > > > > > > > > > > > I agree that the gadgets need to be stored with the Apache Wave > > > > > > > implementation, so that each server hosts the required XML (and > > > CSS, > > > > > JS, > > > > > > > images etc.) files needed. > > > > > > > (This should be ok for federation as long as the gadgets remain > > > fully > > > > > > > accessible from all IPs) > > > > > > > > > > > > > > This would require adding the ability to serve arbitrary files > > > from a > > > > > > > 'gadgets' folder (perhaps mapped to > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://waveserver.com/gadgets/[gadgetname]/[filename].[xml,css,js,png,jpg] > > > > > > > . > > > > > > > > > > > > > > For permitting federation between SSL and-non SSL servers, we > > would > > > > > need > > > > > > to > > > > > > > make this URL available over both irrespective of the state of > > the > > > > wave > > > > > > > server. (Though any real server should be over SSL anyway). > > > > > > > For this to be possible, as part of the WIAB installation, we > > would > > > > > have > > > > > > to > > > > > > > generate valid CA signed certificates simply for serving the > > > gadgets > > > > > > over, > > > > > > > in which case there is no reason to _not_ have the wave server > > over > > > > SSL > > > > > > as > > > > > > > well. > > > > > > > On 19 Sep 2012 12:07, "Bruno Gonzalez" <sten...@gmail.com> > > wrote: > > > > > > > > > > > > > > > I have no idea about all these issues, but given the problems > > > (SSL > > > > on > > > > > > the > > > > > > > > one hand, and 404s after a while on the other hand), it seems > > > > logical > > > > > > to > > > > > > > me > > > > > > > > that Apache Wave keeps a local non-expiring cache of whatever > > > > gadgets > > > > > > are > > > > > > > > used by all its waves. Would that be technically possible in > > all > > > > > cases? > > > > > > > > > > > > > > > > This way, you can be sure you'll be able to read your waves > not > > > > only > > > > > > > today, > > > > > > > > but also a year (or five) from now, without losing > information > > on > > > > the > > > > > > way > > > > > > > > because some unknown company has closed doors (and they > > provided > > > > some > > > > > > > > gadgets). > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 19, 2012 at 12:50 PM, Jérémy Naegel < > > > > > jeremy....@gmail.com > > > > > > > > >wrote: > > > > > > > > > > > > > > > > > I don't know much about SSL but, on a related note about > XML > > > > files > > > > > > > being > > > > > > > > > stored on third party servers and about handling this in > the > > > long > > > > > > term, > > > > > > > > has > > > > > > > > > I see it, a big part of the problem is that, with time, > some > > of > > > > the > > > > > > XML > > > > > > > > > files tend to disappear because their original authors stop > > > > hosting > > > > > > > them. > > > > > > > > > > > > > > > > > > For example, 3 gadgets on the actual jsongadgets.json file > > have > > > > > > already > > > > > > > > > disappeared since the last commit (Google Fight!, Travel > > WithMe > > > > and > > > > > > > > Hostel > > > > > > > > > WithMe)... So, my feeling is that backups of the XML files > > (and > > > > > maybe > > > > > > > > also > > > > > > > > > of the gadgets' thumbnails pictures) should be hosted by a > > > > > dedicated > > > > > > > Wave > > > > > > > > > project to ensure that they're here to stay. > > > > > > > > > > > > > > > > > > +Jérémy <https://plus.google.com/u/0/110860203879684078598 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 19, 2012 at 11:26 AM, Ali Lown <a...@lown.me.uk > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Chrome seems to have changed its default security policy > > > again > > > > in > > > > > > the > > > > > > > > > > last few versions (I am not sure exactly when). > > > > > > > > > > > > > > > > > > > > Previously, when the gadget was attempted to be load > > without > > > > SSL, > > > > > > > > > > whilst the server was running under SSL, Chrome would > > > present a > > > > > bar > > > > > > > at > > > > > > > > > > the top of the screen to ask if this is ok. Until you > > > accepted > > > > it > > > > > > the > > > > > > > > > > gadget would appear 'broken'. > > > > > > > > > > > > > > > > > > > > More recently, Chrome is now silently blocking this > > > 'insecure' > > > > > > > > > > requests so the gadget immediately appears 'broken', and > a > > > user > > > > > is > > > > > > > > > > unable to bypass this (without starting chrome with a > > special > > > > > > command > > > > > > > > > > line flag, which is not a valid workaround). > > > > > > > > > > > > > > > > > > > > There seem to be 3 different servers involved in loading > a > > > > gadget > > > > > > > > > > successfully: > > > > > > > > > > 1) The Wave server hosting the wave > > > > > > > > > > 3) The server hosting the gadget xml file > > > > > > > > > > 2) Some Google interim server (googleusercontent.com) > > though > > > > > which > > > > > > > the > > > > > > > > > > gadget data seems to be loaded. > > > > > > > > > > > > > > > > > > > > If (1) has SSL off, (3) has SSL off then the gadget loads > > > > > > > > > > If (1) has SSL on, (3) has SSL off then the gadget fails > to > > > > load > > > > > > > > > > (2) always seems to use the same settings as (1) so isn't > > an > > > > > issue. > > > > > > > > > > > > > > > > > > > > I am not sure how we can handle this since (most of the > > time) > > > > the > > > > > > > > > > actual gadget xml file is stored on some third party > server > > > > > (which > > > > > > > > > > rarely has SSL support enabled). > > > > > > > > > > > > > > > > > > > > In the mean-time, for the gadgets I am interested in, I > > will > > > be > > > > > > > > > > hacking the jsongadgets.json file (and the gadget xml > file) > > > to > > > > > > point > > > > > > > > > > to my locally (and securely) delivered xml (and > supporting > > > > > > json/css) > > > > > > > > > > files. > > > > > > > > > > > > > > > > > > > > In the longer term, I am uncertain how we should handle > > this. > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > Ali > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Saludos, > > > > > > > > Bruno González > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Jabber: stenyak AT gmail.com > > > > > > > > http://www.stenyak.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Saludos, > > > > > Bruno González > > > > > > > > > > _______________________________________________ > > > > > Jabber: stenyak AT gmail.com > > > > > http://www.stenyak.com > > > > > > > > > > > > > > >
