Re: Is CAP really BEEP-only?

[Stuart Guthrie <sfg@xxxxxxxxxxxx>]

You can create a java web client with BEEPCORE, struts and the J2EE
standard...

Alternatively write a SOAP proxy in java that uses beep to talk CAP.
This could be a client or server implementation. It's another layer but
at least you will be adhering to standards and meeting your user
requirements. I for one would NOT like to see SOAP added to the CA
Protocol as it's thorough enough already. Just write another client for
it and talk to that if you really want SOAP. 

I think some extensions like this are inevitable as the CA Protocol
tries to keep up with the fashion.. I mean software industry.

FWIW


Stuart Guthrie
Team Leader - JiCal 
http://www.jical.org

On Sat, 2004-03-06 at 02:46, Cortlandt Winters wrote:
> Hi Folks,
> 
> It seems that CAP requires that one use BEEP as the underlying transport
> layer. Is this truely the case? I've read the spec and searched through the
> archives, but it seems to be so.
> 
> I understand BEEP's usefullness for things like security and compression,
> and I have read that it improves asynchronous messaging, but as ubiquity and
> interoperability are the key goals of a standard. Would it be possible to
> add a soap level integration point for services to interoperate with their
> calendar data? Are there significant aspects of CAP that couldn't be
> implemented at that level?
> 
> What I would like to do is provide a nicer web based client for folks on
> different platforms to share their calendar data and schedule meetings. It
> seems that since CAP is the current standardization effort that I should try
> and adhere to it, but requireing the use of BEEP makes it difficult to see
> how I can use a web based client. I can work with BEEP in Java or Python,
> but then the users would have a binary install to make and I have to worry
> about multiple platforms. I would prefer to use DHTML, Flash or Curl, and
> use soap headers to communicate to other CAP clients. (Though Curl and Flash
> require an install, their file sizes and installation proceedures are much
> more in line with what I think an average user will be willing to follow.)
> 
> I know I could create a decent scheduling app using the older formats and my
> own messaging solutions, but I'd rather do things right if I can. I
> appreciate the requirements and design work this group has done and it's
> improved my understanding of what direction to go in in general. I will
> understand if small developers like myself are not in the scope of CAP's
> target audience, but the sheer number of web based calendar clients suggests
> that it might be worth accomodating that part of the developer base with a
> soap interoperability layer.
> 
> Any thoughts appreciated.
> 
> Thanks
> 
> Cortlandt Winters
> 
>