incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zachary “Gamer_Z.” Yaro <zmy...@gmail.com>
Subject Re: Wave Extensions Gallery
Date Thu, 03 Jan 2013 07:19:43 GMT
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.ngl@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
> <zmyaro@gmail.com>wrote:
>
> > Responses inline below...
> >
> > —Zachary “Gamer_Z.” Yaro
> >
> >
> > On Thu, Sep 27, 2012 at 2:48 AM, Bruno Gonzalez <stenyak@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
> > > <zmyaro@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.lown0@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" <stenyak@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.ngl@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 <ali@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message