incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yuri Z <vega...@gmail.com>
Subject Re: Wave Extensions Gallery
Date Thu, 03 Jan 2013 09:05:10 GMT
http://wavygallery.appspot.com/api/v0/list.json?type=gadget causes an error


On Thu, Jan 3, 2013 at 9:19 AM, Zachary “Gamer_Z.” Yaro <zmyaro@gmail.com>wrote:

> 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