Appreciate the insight, Ian. For another project taking the tactic you have
about skipping client protocol is viable. Alas, for the one I had in mind it
just means we're gonna have to push off Wave integration until a proper
client protocol is defined. I really can't imagine what they were thinking
making the current complex monster when a functionally complete one could
have been simply made in the first place. It has clearly added to the
confusion (and thus, extremely limited adoption) of wave.

  -- Ben

On Tue, Dec 1, 2009 at 10:58 PM, Ian Roughley <[email protected]> wrote:

> No pulse is not open source, and there are no plans to expose our C/S
> protocol (APIs but not C/S).
>
> From what I know, what you're looking for doesn't currently exist.  So the
> options seem to be to do
> what we're doing, with the server being FedOne; or start a C/S protocol :-)
>
> Good Luck!
>
> /Ian
>
> proteus guy wrote:
> > Ian,
> >
> >     Yes we need a client/OT implementation initially and our next stage
> > is to expose some applications at the server level as waves. We know the
> > C/S protocol is going to be redone but were hoping for a quick win to
> > integrate an existing app front end with wave but doesn't look like
> > that's going to be an option right now.
> >
> >     I like your idea of using a federated wave server as a middle-ware
> > of sorts but it's not appropriate for our initial requirements. I don't
> > suppose Pulse is Open Source? :-)
> >
> >   -- Ben
> >
> > On Tue, Dec 1, 2009 at 9:50 PM, Ian Roughley <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     We have our own client (and server for that matter) at Novell with
> >     Pulse.
> >
> >     The question you ask is a little tricky as it's unclear whether
> >     you're integrating at the
> >     server/federation level or the client/OT level (this is what I
> >     suspect you want).  Having waves in
> >     the client would be nice, but I'd assume that at some point you'd
> >     want to keep some of this
> >     information in your application and always routing waves through the
> >     client seems very inefficient.
> >
> >     If it is the later, I think you're out of luck for some time (for
> >     C/S protocol).  What we found was
> >     that the C/S protocol (even though it would be nice to have to slap
> >     a new face on an existing
> >     server) was not particularly important.  Instead we have a
> >     federatable server that our client talks
> >     to, and to provide compatibility with wave we took the OT code (from
> >     FedOne) and compiled it using
> >     GWT into a JS library - if you take this route, the JS will be
> >     language agnostic.  The communication
> >     between our client and server is then our choice, and can be swapped
> >     around if necessary.
> >
> >     Hope this helps,
> >     Ian
> >
> >     proteusguy wrote:
> >     >     We're looking to integration Google Wave with an existing
> >     > application (web services with python/javascript) and need an
> >     > implementation of the client protocol in either (preferably)
> javscript
> >     > or python. The existing GWT-based one is simply not going to work
> for
> >     > us and we don't want to have to deal with Java. I understand that
> the
> >     > ultimately client protocol is a "work-in-progress" to put it
> politely
> >     > but we just want to have a clean client access to the current wave
> >     > server to get this initial product integration done. Appreciate any
> >     > pointers/advice.
> >     >
> >     >   -- Ben Scherrey
> >     >
> >     > --
> >     >
> >     > 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] <mailto:
> [email protected]>.
> >     > To unsubscribe from this group, send email to
> >     
> > [email protected]<wave-protocol%[email protected]>
> >     
> > <mailto:wave-protocol%[email protected]<wave-protocol%[email protected]>
> >.
> >     > For more options, visit this group at
> >     http://groups.google.com/group/wave-protocol?hl=en.
> >     >
> >     >
> >
> >     --
> >
> >     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]
> >     <mailto:[email protected]>.
> >     To unsubscribe from this group, send email to
> >     
> > [email protected]<wave-protocol%[email protected]>
> >     
> > <mailto:wave-protocol%[email protected]<wave-protocol%[email protected]>
> >.
> >     For more options, visit this group at
> >     http://groups.google.com/group/wave-protocol?hl=en.
> >
> >
> >
> > --
> >
> > 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]<wave-protocol%[email protected]>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/wave-protocol?hl=en.
>
> --
>
> 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]<wave-protocol%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/wave-protocol?hl=en.
>
>
>

--

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