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
>
