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