Re: Is CAP really BEEP-only?

["Cortlandt Winters" <cort@xxxxxxxxxxxxxxxxxxx>]

Hi Stewart,

Thank you for the response. I take it (in sum) to confirm that
I'm not mistaken and that BEEP is currently a requirement.

>You can create a java web client with BEEPCORE, struts and the
>J2EE standard...
I'd be attracted to using Java for the client, but as I mentioned
in my previous message, the runtime is larger than what I believe
the average web user will be willing to download and install
for a web client(about 15MB).

>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.
This scenario really only works for the server side because of the size
mentioned above, and then only my server can speak to other's servers or
clients. My client can not. It also forces me to write a server, which is
not my intent.  My intent is to create a client to interoperate with the
servers of others. Finally, this technique eliminates any possibility of an
offline mode.

Calendaring and scheduling is the classic example of where you want your
client to maintain it's own state, be as ubiquitous as possible and work
offline if possible. History suggests to me that there will be plenty of
excellent CAP web servers and few, if any, excellent CAP web clients -
especially ones that are cross platform, easy to install and which can work
offline. That may sound like a lot, but that's the task isn't it?

I did find out about another option for anybody who is similarly interested.
There is apparently a javascript beep implementation for Mozilla. And a
Mozilla icalendar project. The only problem is yet again the 10+MB download
for Moz with another download for the calendar. I could get my friends to
download a browser, but not my father or niece, which is part of the
intended user group.

>I think some extensions like this are inevitable as the CA
>Protocol tries to keep up with the fashion.. I mean software
>industry.
That is good news. I would support this direction. It would combine the low
level benefits of beep with a slower, but more ubiquitous option, which for
a calsh standard is critical. A standard doesn't truely become a standard
until it can be taken for granted and I think that such an extention would
be helpfull to that goal.

It sounds like this is the proper process and it would address my concerns.

I hope these mundane implementation concerns are not off-topic. Please just
consider them grist for the mill and honest feedback about the practical
implications of using BEEP, rather than opinionated criticism. I trust that
there are good reasons for using BEEP which offset the negatives and that
when the SOAP extention is created, it won't have to jump through too many
extra hoops because of the beep lower layer.

Thanks again for responding.

Cortlandt Winters

>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
>>
>>