incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blossom <jblos...@gmail.com>
Subject Re: Moving Wave Forward
Date Wed, 29 May 2013 15:09:43 GMT
ahmet,

Well, certainly native is one way to go, and if we have an API toolkit
developers could go that way, especially if the core services in the demo
apps are HTML5-based - just wrap a native app container around that, as
many developers do. And perhaps there are demo clients for iOS and Android
also. But looking at the timeline for all of this, I would hope that core
development would anticipate the eventual decline of platform-specific Web
apps and optimize for mobile Web apps that live in browser-space. The
"gorilla in the room" in all of this is Google, and they are pushing hard
via Chrome Packaged apps to do just that, with similar "hooks" for Web apps
being developed by Mozilla for Firefox. This is one of the reasons that
they came out with the Chromebook Pixel - to get developers creating apps
for browsers to deliver more touchscreen-aware capabilities. There's that
in-between space of latptops and tablets that are becoming more
touch-enabled, and this is where Wave clients are likely to succeed. So if
we optimize for mobile browser experiences now, just as the right tools are
coming on line to develop those capabilities, Wave could be at the right
place at the right time and become a "killer app" platform for mobile Web
browser-based apps, as well as supporting native clients. At least that's
my thinking, and I hope that others offer their best thinking on this.

Many thanks,

John

On Wed, May 29, 2013 at 8:38 AM, Ahmet Rasit <ahmet@seyrah.com> wrote:

> i think best way for wave is native mobile clients.
>
>
> On Wed, May 29, 2013 at 1:43 PM, Thomas Wrobel <darkflame@gmail.com>
> wrote:
>
> > Would it be correct to say the steps towards multiple clients (both
> desktop
> > and mobile) would be:
> >
> > 1. Separate out the server and client code we have atm. (hard/long job?)
> > 2. Formalize a working protocol between the client and server.
> > 3. Document this protocol nicely.
> > 4. Implement this protocol into a library so it can be used easily by
> > anyone making a client, also making updating those
> > clients easier if the protocol changes. (just put in a newer version of
> the
> > library).
> > 5 (option) Ports of that library to a few languages.
> > 6. Hopefully mobile and alternative clients appear using these libs.
> > ?
> >
> > The first parts would need to be done by Apache, but possibly 4/5/6 can
> all
> > be left to 3rd parties.
> > -Thomas
> >
> > On 29 May 2013 10:37, Pratik Paranjape <pratikparanjape@gmail.com>
> wrote:
> >
> > > p.s. I was able to setup (server-to-server) federation long back, I
> > think a
> > > few months after Google IO10, it was not easy, but it had worked. Back
> > then
> > > there were quite a few guides available.
> > >
> > >
> > > On Wed, May 29, 2013 at 1:50 PM, Pratik Paranjape <
> > > pratikparanjape@gmail.com
> > > > wrote:
> > >
> > > > Hello John,
> > > >
> > > > It was good to see the presentation, thank you for putting it out.
> > > > Ambitious but tempting.
> > > >
> > > > I would like to comment and emphasize on couple of things others have
> > > > rightly said before:
> > > >
> > > > 1) Federation as defined in Wave-protocol is collaboration among the
> > > > servers of different organizations to exchange the wave/wavelets e.g.
> > > Wave
> > > > server under domain acmedotcom communicating with wave server under
> > > > zuludotcom, in real time. This has always been an implemented feature
> > of
> > > > the wave code base and was one of the first features released by the
> > > Google
> > > > team. Protocol evolution was left open ended for changing
> requirements
> > > > depending on adoption.
> > > >
> > > > If I understood correctly, you are using the word federation as in
> > > > allowing different devices communicating with each other. This
> feature
> > is
> > > > really a byproduct of good server design. All communication WILL have
> > to
> > > go
> > > > through server. As long as the server endpoints and data models are
> > well
> > > > defined, its possible for anyone to write a client and represent the
> > > > fetched data in any desired format. In other words, Federation at its
> > > > core : Any device can federate with any other, is actually adoption
> > > > dependent and will not require special design for Wave. Encouraging
> > > > development of host of such clients. possibly providing samples, can
> > > > definitely be a point.
> > > >
> > > > 2) Even though there are several spots for serious improvements in
> wave
> > > > code ( mostly because of the new technologies and current Browser
> > > landscape
> > > > especially atuned to a product like wave: new editors, reactive
> servers
> > > > like node and play!, faster databases like mongo and redis), it will
> be
> > > > unwise to throw away the code and start from scratch (Reference:
> > > > Deprecating Java Code in slides ). Its not a small project by any
> > > > consideration and as Michael pointed out, unless there is sudden
> inflow
> > > of
> > > > a number of developers, its not going to be easy to make big changes
> > even
> > > > for a commercial entity. Best way would be to put up issues one by
> one
> > > and
> > > > go through solving them (as the team is doing currently). Re-design
> and
> > > new
> > > > architecture, which is undeniably necessary, will have to evolve
> > through
> > > > this path.
> > > >
> > > > Hello Michael,
> > > >
> > > > 2)
> > > >> The current codebase is largely a proof of concept.  It has some
> > > >> potential, but I think most of us would agree that some time spent
> > > >> re-architecting how we want things to work and morphing the code
> base
> > > into
> > > >> that (or rewriting it) would be in the projects best interests.
>  Again
> > > if
> > > >> we have a roadmap and people who feel strongly about working on
> those
> > > >> areas, we can divide and concours.
> > > >
> > > >
> > > >
> > > > Thanks for acknowledging
> > > > this
> > > > .
> > > > Coming from someone who has been involved with Wave since very early,
> > it
> > > > makes the point official. It will indeed first step to prepare a road
> > map
> > > > and get agreement on a list of necessary changes. I had posted a list
> > in
> > > > one of the earlier messages.
> > > > Of course as Upayavira has pointed out, everything of it will depend
> on
> > > > the developer interest, which is not up to the same level as proposed
> > > > changes at this moment.
> > > >
> > > > Wishing best for Wave.
> > > >
> > > > Pratik Paranjape
> > > >
> > > >
> > > > On Wed, May 29, 2013 at 9:10 AM, John Blossom <jblossom@gmail.com>
> > > wrote:
> > > >
> > > >> Dave,
> > > >>
> > > >> Thanks, I think that we're on the same page. No doubt that Wave
> > > federation
> > > >> holds out tremendous promise. Hopefully the Apache community can
> move
> > > >> towards deciding how they'd like to progress towards more advanced
> > > goals.
> > > >> I
> > > >> welcome any and all suggestions to that end.
> > > >>
> > > >> Best,
> > > >> John
> > > >> On May 28, 2013 11:08 PM, "Dave" <wave@glark.co.uk> wrote:
> > > >>
> > > >> > John,
> > > >> >
> > > >> > Sorry, I wasn't trying to say that wiab provides the mobile client
> > > that
> > > >> > you are looking for, just that the wave federation concepts and
> > their
> > > >> > implementation in the wiab server are likely to be a good fit
for
> > your
> > > >> > usecases. You suggested that the federation paradigms needed
a
> > > complete
> > > >> > re-think for a "mobile-first world", and my understanding is
that
> > this
> > > >> > isn't the case.
> > > >> >
> > > >> > So while federation and the "server" component sound like a
> > reasonable
> > > >> > fit, the mobile _client_  (supporting off-line access etc.)
> doesn't
> > > >> exist
> > > >> > yet.
> > > >> >
> > > >> > Over the years there have been a few discussions about formalising
> > the
> > > >> > client/server protocols within wiab - but so far there hasn't
been
> > the
> > > >> > manpower to implement it.
> > > >> >
> > > >> >
> > > >> > Dave
> > > >> >
> > > >> >
> > > >> > On 29/05/13 03:30, John Blossom wrote:
> > > >> >
> > > >> >> Dave,
> > > >> >>
> > > >> >> I think that you've captured much of both the paradigm and
the
> > > paradox.
> > > >> >> Wave could - and should - be able to do these things, but
in the
> > > >> existing
> > > >> >> kit you really cannot do it for many of these points, and
where
> it
> > > >> does do
> > > >> >> it one cannot say that the mobile-Web interface is elegant.
In
> none
> > > of
> > > >> the
> > > >> >> cases, AFAIK, does it deal with the case of people initiating
new
> > > Waves
> > > >> >> offline on a mobile device and adding in applets or shifting
to
> > > >> different
> > > >> >> UIs for the same wave. Also not covered in the mobile client
is
> the
> > > >> >> potential for peer-to-peer mobile Wave communication. This
will
> be
> > of
> > > >> >> particular importance to "next billion online people" markets.
I
> > > agree
> > > >> >> that
> > > >> >> with connectivity, the client may communicate to a primary
server
> > for
> > > >> >> further downstream federation for specific waves (other servers
> for
> > > >> other
> > > >> >> waves, if done properly, if there is not node-to-node
> credentials,
> > as
> > > >> in
> > > >> >> company X only wants to communicate with mobile clients
> directly).
> > > The
> > > >> >> email analogy is certainly clear, but Wave federation and
> > > client-server
> > > >> >> functions need to focus first on getting waves to support
> multiple
> > > Wave
> > > >> >> UIs, so that there will be compelling reasons to build out
> > federation
> > > >> for
> > > >> >> email support, via presentation layer adapters.
> > > >> >>
> > > >> >> So if the client/server break is/can be formalised in code,
then
> we
> > > can
> > > >> >> move towards a mobile-capable HTML5/JS client which is efficient,
> > > >> robust,
> > > >> >> supports multiple UIs on top of the same data sets, and which
can
> > > have
> > > >> >> offline, server-like functions which can enable peer-to-peer
> > > >> federation.
> > > >> >>
> > > >> >> I may not be completely up to speed on the current architecture's
> > > >> status,
> > > >> >> but so far the responses that I am receiving seem to confirm
> where
> > > the
> > > >> >> architecture needs to adapt to modern requirements and
> performance
> > > >> >> expectations. Hopefully we can all work together to address
the
> > huge
> > > >> >> opportunities that those requirements present.
> > > >> >>
> > > >> >> Thanks,
> > > >> >>
> > > >> >> John
> > > >> >>
> > > >> >> On Tue, May 28, 2013 at 9:54 PM, Dave <wave@glark.co.uk>
wrote:
> > > >> >>
> > > >> >>  John,
> > > >> >>>
> > > >> >>> I'm not a committer, but I have some familiarity with
the wave
> > > stack.
> > > >> >>>
> > > >> >>>
> > > >> >>> On 29/05/13 01:23, John Blossom wrote:
> > > >> >>>
> > > >> >>>  People need their waves to live on their mobile devices,
not
> just
> > > on
> > > >> >>>> cloud Web servers. After all, email provides local
mobile
> offline
> > > >> >>>> capabilities.
> > > >> >>>>
> > > >> >>>>  I think you might not be 100% up to speed with some
of the
> Wave
> > > >> >>> architecture. In an email world, people have mobile off-line
> > access,
> > > >> but
> > > >> >>> they still use email servers.  The email server often
has the
> > > >> definitive
> > > >> >>> copy of their email [i.e. imap], and mobile just retains
a
> cached
> > > >> copy.
> > > >> >>> In
> > > >> >>> a mobile world, you still need a permanent server address
to
> > deliver
> > > >> mail
> > > >> >>> to, or send it through.
> > > >> >>>
> > > >> >>> This is the same with wave:
> > > >> >>>
> > > >> >>> client <---c---> server <---f---> server
<---c---> client
> > > >> >>>
> > > >> >>> The federation protocol [f] sits between the two servers,
and to
> > > >> support
> > > >> >>> mobile clients you would expect those clients to:
> > > >> >>>   - maintain cached waves
> > > >> >>>   - allow off-line access to those waves
> > > >> >>>   - allow off-line changes to those waves
> > > >> >>>   - propagate changes in real-time where possible
> > > >> >>>
> > > >> >>> In theory a wave server can support different clients.
> > Unfortunately
> > > >> in
> > > >> >>> the current wiab codebase, there is only one client -
which is
> the
> > > >> >>> bundled
> > > >> >>> web-client. The current code base does sort-of have the
logical
> > > >> >>> client/server separation as outlined above (though some
code is
> > > shared
> > > >> >>> between the server and the client), but there isn't a
formally
> > > defined
> > > >> >>> client protocol [c], or separation of the web-client.
> > > >> >>>
> > > >> >>> So in a broad sense, to support mobile one would need
to:
> > > >> >>>   - formalise the client-server protocol [c]
> > > >> >>>   - implement that in WIAB (ideally allowing Server and
> web-client
> > > to
> > > >> be
> > > >> >>> deployed separately)
> > > >> >>>   - implement your mobile clients.
> > > >> >>>
> > > >> >>> Any mobile client would still communicate through a server
(as
> > email
> > > >> does
> > > >> >>> today) allowing (among other things) third parties to
interact
> > with
> > > >> waves
> > > >> >>> whilst _I_ am offline.
> > > >> >>>
> > > >> >>>
> > > >> >>>   So if you are considering the possibility of a mobile-first
> > world,
> > > >> you
> > > >> >>>
> > > >> >>>> really do need to
> > > >> >>>> rethink existing Wave federation paradigms seriously.
> > > >> >>>>
> > > >> >>>>  There may be some corner cases which would need
tweaking, but
> my
> > > >> >>> understanding is that the core wave federation paradigms
/
> > protocol
> > > >> (and
> > > >> >>> the wiab federation implementation) suit mobile very
well. They
> > were
> > > >> >>> explicitly designed to support real-time when online,
and
> > > disconnected
> > > >> >>> access when offline.
> > > >> >>>
> > > >> >>> Someone please correct anything I've got wrong!
> > > >> >>>
> > > >> >>> Dave
> > > >> >>>
> > > >> >>>
> > > >> >>>
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
>
>
> --
> ahmet raşit demirkan
> SeyRah bilişim
> www.seyrah.com +902125217678
>

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