incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pablo Ojanguren <pablo...@gmail.com>
Subject Re: Collaboration JavaScript API for Wave
Date Thu, 04 Dec 2014 16:28:26 GMT
Hello,

Thomas, you are right. The server has been extended but no so much.
The other part is the client API. You can develop your Web App
(Java/Android very soon) using the API
to manage their data. The app could use any server with the extension. Any
app knowing how is your data model could communicate with yours from any
wave server.

Data models are basically build with maps, lists and strings. The idea is
that servers provide additional functionality to the apps in order to
manage the instances of data models of each app , for example searching.

In summary, instead of conversations you can have any other data. Instead
of one client app you can have different ones.





2014-12-04 14:19 GMT+01:00 Thomas Wrobel <darkflame@gmail.com>:

> Can I clarify how this works;
> If a few people ran wave servers with this extension, could they federate a
> few different data models? (ie, this one extension would allow different
> users using wave for different things, and provided other severs have the
> same extension, they can all talk to eachother?)
>
> Is so, this sounds like it might be a good fit for my ARwave.org project
> which has been in a holding pattern for awhile.
> With it I was trying to leverage wave for federated realtime collaborative
> editing of geolocated billboards. (so, letting people annotate the world
> and share their annotations).
>
> Had it working back under google wave - I simply was using a crude
> serialised data but was also playing with key/value pairs in annotations.
> Was functional, tested it with 3 people at least on a few platforms. One
> person could post a flag on a googlemap webapp, and other people saw it in
> the right place in a AR view on their phones. It was a very crude
> implementation though. Relaying on a serialised string doesnt make it very
> backwards/forward compatible easily.
> My sticking point was mostly also the  lack of a client server protocol - I
> wanted my code to work on any wave server as I didn't have the time or
> skills to developed my server side as well as the client.
>
> It sounds like your project might, possibly, sort of, be a good fit for
> mine. If it will deal with, say,Web or Android to Wave communication, and
> also lets me use a better model then "make everything into a string".
>
>
>
> ~~~
> Thomas & Bertines online review show:
> http://randomreviewshow.com/index.html
> Try it! You might even feel ambivalent about it :)
>
> On 3 December 2014 at 23:06, Pablo Ojanguren <pablojan@gmail.com> wrote:
>
> > Oh, Goodow is really cool!
> >
> > The difference is that my API implementation is pure Wave, so it works on
> > the federated/distributed infraestructure and it inherits the
> participants
> > model. These aspects are what we would like to keep and why we like Wave.
> >
> > Apart from that, Goodow OT data type is JSON (instead of XML) and uses
> new
> > technologies like vertx...  and also it provides iOS and Android clients
> > -but we are going to provide a Java/Android client soon-.
> >
> > Personally I think the federation protocol and participation model are
> the
> > strongest features of Wave today, as long as UIs has become more powerful
> > and new team-collaboration tools are emerging.
> >
> > Thank you for the reference Yuri.
> >
> >
> >
> >
> > 2014-12-03 9:31 GMT+01:00 Yuri Z <vega113@gmail.com>:
> >
> > > Interesting, how does it compare to
> > > https://github.com/goodow/realtime-store?
> > > Which I believe is based on walkaround  OT implementation.
> > >
> > > On Tue Dec 02 2014 at 1:09:55 AM Pablo Ojanguren <pablojan@gmail.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I would like to introduce something I have been working on during
> past
> > > > months in the context of my current job.
> > > >
> > > > I have developed *a generic JavaScript API working on top of Wave*.
> > It's
> > > > quite similar to the Google Real-Time API, providing similar
> observable
> > > > data types: maps, lists and strings.
> > > >
> > > > The API works right now but it needs some work to become a fully
> usable
> > > > API, for example to add OAuth...
> > > >
> > > > It also would be valuable to add a customizable search index to query
> > the
> > > > shared data models.
> > > >
> > > > Source code can be found at: *
> > https://github.com/P2Pvalue/incubator-wave
> > > > <https://github.com/P2Pvalue/incubator-wave>*
> > > > The README.md file provides a basic user guide to install and use the
> > > API.
> > > >
> > > > Of course any kind of comments are welcome.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Pablo
> > > >
> > >
> >
> >
> ~~~
> Thomas & Bertines online review show:
> http://randomreviewshow.com/index.html
> Try it! You might even feel ambivalent about it :)
>
> On 2 December 2014 at 00:09, Pablo Ojanguren <pablojan@gmail.com> wrote:
>
> > Hello,
> >
> > I would like to introduce something I have been working on during past
> > months in the context of my current job.
> >
> > I have developed *a generic JavaScript API working on top of Wave*. It's
> > quite similar to the Google Real-Time API, providing similar observable
> > data types: maps, lists and strings.
> >
> > The API works right now but it needs some work to become a fully usable
> > API, for example to add OAuth...
> >
> > It also would be valuable to add a customizable search index to query the
> > shared data models.
> >
> > Source code can be found at: *https://github.com/P2Pvalue/incubator-wave
> > <https://github.com/P2Pvalue/incubator-wave>*
> > The README.md file provides a basic user guide to install and use the
> API.
> >
> > Of course any kind of comments are welcome.
> >
> >
> > Regards,
> >
> > Pablo
> >
>

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