Hi to all,

My question is: There are some official news from google about what is
going to happen to Google Wave Technology?

IMHO, closing Google Wave Product it does not mean, at least to me,
Google is going to forget all investment done on wave technology and
gift
all this technology to us to continue working on it, (I hope it to
happen anyway!)

I love everything I read on last emails because I feel there are
people, permit me to include mysef, that will continue working on this
technology in the case Google discontinue it that is a
very good thing.

A lot of emails and opinions I've read are so smart and there are
really interesting proposals and forecast analisys about current
state
and future steps to Wave, including what are the complex and less
complex areas to work on...
(thank you Torben and others...)

We had open a lot of discussions on this thread but sorry me, we have
no news about what is going to happen even if we'll able to 'bit' this
as open source...

Of course we can continue talking and is quite interesting!

 but we don't really know how it could be as is Google who has the
last word.

Now continue with discussion, Hi Ian, nice to meet you...

To ignore OT on initial Implementations for Federation will make sense
only if you want to
have federation-proxies maybe with 'Isolated Domain' features
forwading deltas to a wave-provider with FULL OT
implementation, that is deferring to a secondary domain wave hosting,
management and storage, so secondary domain can
behave 'on behalf' of non-OT server.

I prefer to foresee a isolated set of OT Providers for differente
schemas, (schema=data type), with different
level of OT algorithms as proposed sometimes on this thread, (even by
you?), then people wanting to implement/install a full-XMPP-Federation-
Wave-Providers
only need to implement a layer, (proposed by someone on thread), that
can talk to OT Providers, (local or remote), so you reduce
server implementation complexity as Wave-Providers looks for serve
clients and federate while they are able to ask OT Providers to
support WDT (wave data types)

This is a great problem in wave, now as google have isolate their work
to Google Wave 'as-is' is easy to block everything, but... if I want
to include new wdt=wave-data-type on wave, like the internal meta-
structure I use to wave-vs.net? only our server is able to handle
this.... what if a customer have it's own server like Novell Pulse? is
a mess...

How fedone will support it natively? is not possible, but If I publis
a OT specific server in a 'global directory' so FedOne or any other
implementation for
Wave-Server can ask my OT Server to solve concurrency problem? you
have make an automatically scalable platform..

Of course this only one problem of thousand we'll have.

Maybe this is the way or maybe not... we'll discuss if Google give us
the chancel we'll see


Jesus Salas
wave-vs.net











On 8 ago, 00:50, Joel Dietz <[email protected]> wrote:
> Dear Ian,
>
> I understand your concern re: the JS Editor but not all of the
> particulars. What is Novell using as a client?
>
> As far as I am aware there is nothing out there available but Google
> promised to deliver something eventually. Also, AFAIK, there has been
> no discussion of the integration of OT w/ other Google products, which
> must use an lightweight but functional editor (Splash?) different than
> the one currently in use at the Wave Preview.  If we get some greater
> part of that open sourced we can potentially iterate on it.
>
> Hard to say much more than that now, but I completely agree with you
> that the JS Editor + WFP + OT all have to be in place for there to be
> any real viability for Wave. Each needs to be open sourced and part of
> an open, public decision making organization so that improvements can
> be made. It seems that most of us are agreed on that.
>
> Regards,
>
> Joel
>
> On Aug 5, 11:11 pm, Ian Roughley <[email protected]> wrote:
>
>
>
> > The short answer is yes, both from Novell Pulse and me personally.
>
> > I believe that federation is one feature that was truly going to liberate 
> > the data, making it
> > available cross-boundaries.  It's the reason why email succeeded, and it 
> > would enabled true
> > collaboration.
>
> > My concern is that WFP is tightly coupled with OT, and OT is complex.  It 
> > is no small feat (trust me
> > I know from experience) in taking existing editors and infrastructure, and 
> > replacing it with
> > OT-enabled infrastructure in an existing product.  And translating between 
> > "normal" (text/xml/etc.)
> > content and real-time OT content leads to problems.  So convincing vendors 
> > to make this leap is
> > going to be difficult.
>
> > One thing that no one has addressed on this list is that by continuing WFP 
> > you also need to continue
> > OT and the JS editor.  If you don't have a strong fully-featured non-buggy 
> > editor that
> > people/companies can use without developing themselves, OT won't be 
> > continued or used.  Without OT,
> > the WFP protocol breaks down.  It's all a mini-ecosystem.
>
> > I wonder whether a slightly different protocol that would allow for the 
> > federation of existing
> > non-real-time content as well as real-time content would be received better 
> > by the community. One
> > that avoided the need for significant code changes, and one that would 
> > allow services to federate
> > any type of content.
>
> > Ian Roughley
> > Pulse Platform Architect.
>
> > On 08/05/2010 08:11 PM, James Purser wrote:
>
> > > Hi Ian,
>
> > > Thanks for the update from Novell.
>
> > > Given that one of the features that Pulse was pimping was the ability
> > > to conduct federated conversations, do you think Novell would be
> > > interested in continuing to be involved in developing the Federation
> > > protocol?
>
> > > I know you probably can't answer right away, I'm just trying to get a
> > > feel for who, corporately would be interested in furthering the wave
> > > tech.
>
> > > James- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -

-- 
You received this message because you are subscribed to the Google Groups "Wave 
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/wave-protocol?hl=en.

Reply via email to