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 > > >
