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 16:06:27 GMT
Michael,

Sounds like we're all starting to sync up on this bit by bit. The SMTP/IMAP
analogy is correct, though with different services, of course.

I am certainly open to who maintains the raw reference client. Given that
the platforms for that client are not really in Apache's typical line of
projects, AFAIK, perhaps the API is where we draw the line, but there would
have to be an equivalent body providing similar development and maintenance
services as the Apache server code evolves. It may start one way, then go
another way, whatever, it's doable either way. Regardless of who develops
the reference client, clearly testing via the reference client would be
part of the Apache Wave server release process. The key thing is to enable
client apps to evolve rapidly with the right organizational structure
focused on client apps commercialization, evangelization and education.

If we can get a little more clarity on feasibility and roles, perhaps we
can start to move this to a more public realm. I don't think that we're
quite there yet, but we're a lot closer than we were 24 hours ago.

Thanks,

John

On Wed, May 29, 2013 at 11:46 AM, Michael MacFadden <
michael.macfadden@gmail.com> wrote:

> In my opinion, we don't really have a client server protocol at all. What
> we have is have code passing protobuffs over web sockets or SocketIO. The
> current situation is that the client and server code are intertwined due to
> its implementation in GWT and the desire to use the same code in both, just
> cross compiling parts into the web client.
>
> I think the server and client should be divorced. My opinion is that we
> should pattern after email where the federation protocol would equate to
> SMTP and the client server protocol would equate to IMAP.
>
> That said I think apache would still be responsible for developing a
> REFERENCE client to demonstrate the server. I think we could also offer
> client APIs written in different languages to facilitate client
> development. The rest of the client development could happen in other
> projects.
>
> Again just my opinion.
>
> ~Michael
>
> On May 29, 2013, at 8:35 AM, Thomas Wrobel <darkflame@gmail.com> wrote:
>
> > " we need an updated version of a demo app in the
> > most ideal language - generic as in today's WiaB client but a testbed for
> > services that can be adopted easily into much more targeted apps."
> >
> > Id agree with that, although I'd suggest that app be targeted towards
> > developers rather then end users.
> > That is, it doesn't have to be refined, or "cutting edge", but it does
> have
> > to clearly provide a framework from which others
> > can see exactly how to use the protocol.
> >
> > I think that will be the surest way to actually get great clients - not
> to
> > try to take it all on at Apache, but provide a framework for other
> > developers to do so. I would guess theres probably hundreds of times more
> > mobile developers able to make nice clients then there is those able to
> > work on the sever. I admit this is just a hunch - but I personally know
> at
> > least 3 people who would do so given a chance.
> > --
> >
> > Regarding "ideal language" - that one might be a tough call;
> >
> > For web clients GWT is still a very good choice for desktop. It has to be
> > Javascript running on the browser  alternatives simply arnt anywhere
> mature
> > yet.  But GWT provides a nice way to make that javascript.
> > Theres  alternatives that should be looked into , but its certainly still
> > one of the easiest ways to build webapps that are highly optimized and
> yet
> > work almost identically on all browsers. By using gwt to write Java which
> > compiles to  Javascript it saves a lot of time and effort.
> >
> > How well GWT preforms on mobile, however, I really dont know. Small GWT
> > apps tend to be a lot bigger then working directly in
> > javascript...however...big GWT apps tend to be a lot smaller. That is, it
> > starts bigger, but scales very well.
> > So it probably depends on the form of the end client the best way to do
> it.
> >
> > In either case, Id suggest any c/s library itself would just be made in
> > Javascript.
> > GWT clients would have to make a wrapper for it (but this is a easy
> task),
> > meanwhile by having the library j/s means people not wanting to use GWT
> for
> > web apps can still use the lib. This gives client developers a lot more
> > options.
> >
> > The only downside would be ports would be need to be made for Native
> > clients. But thats pretty unavoidable whatever we do.
> >
> >
> >
> > On 29 May 2013 16:59, John Blossom <jblossom@gmail.com> wrote:
> >
> >> Thomas,
> >>
> >> You have laid out the correct roadmap overall, I think. I'd add a little
> >> icing on the cake - in addition to a well-defined developer API toolkit
> (my
> >> interpretation of 1-4), we need an updated version of a demo app in the
> >> most ideal language - generic as in today's WiaB client but a testbed
> for
> >> services that can be adopted easily into much more targeted apps.
> Perhaps
> >> we would need two or more generic apps, to show general use capabilities
> >> and how to target them.
> >>
> >> I think that you bring up an important point - Apache owns the whole
> stack,
> >> which apparently is still an intertwining of server-side and client-side
> >> functionality. I agree that Apache's role is best suited for 1-3. With
> that
> >> said, though, if the rest is up to other people, we will need Apache's
> >> support in allowing the Wave brand to encompass the Apache Wave Web
> server
> >> components supported by them and the API-plus-apps-toolkit supported in
> >> open source format by another organization. I don't want to presume
> what's
> >> right or wrong here, I am only laying out what seems logical so that ASF
> >> can consider this and help us to formulate an appropriate course of
> action.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >> On Wed, May 29, 2013 at 6:43 AM, 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
> >>
>

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