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