Subject: RE: OPES protocol, pre-draft

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 21 Feb 2003 13:17:28 -0500

hi,

see inside please.

abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Friday, February 21, 2003 12:42 PM
> To: [email-masked]
> Subject: RE: OPES protocol, pre-draft
> 

> I agree that calling OPES protocol ICAP may help OPES 
> acceptance/deployment for non-technical reasons. To save time 
> and flames, I suggest to avoid the naming issue until OPES 
> protocol is shaped and the consensus is, in fact, that it is 
> better than ICAP/1.0.
> 
> Thank you,
> 
> Alex.

Let us be carefull here. So far my main concern with the proposed protocol
is that it looks a lot like ICAP.  The main scenarioes that are solved so
far are basically packaging (or passing )a request to the callout server,
with all the technicalities.

We need to start thinking about scenarios that involves the user
preferences, that include the choice of obtaining a service from more than
one source etc..

It is far too early to start even thinking about naming the OPES callout
protocol ICAP xxxx.

abbie

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 21 Feb 2003 11:23:14 -0700 (MST)

On Fri, 21 Feb 2003, Abbie Barbir wrote:

> Let us be carefull here. So far my main concern with the proposed
> protocol is that it looks a lot like ICAP.  The main scenarioes that
> are solved so far are basically packaging (or passing )a request to
> the callout server, with all the technicalities.
>
> preferences, that include the choice of obtaining a service from
> more than one source etc..
>
> It is far too early to start even thinking about naming the OPES
> callout protocol ICAP xxxx.

I agree with all of the above. The major challenges are still ahead.
Message passing is just one (most performance-sensitive, but not the
most difficult) part of the protocol.

Alex.