Subject: RE: OCP transport vote, commitment

From: "Martin Stecher" <[email-masked]>
Date: Sat, 10 May 2003 22:54:29 +0200

On Fri, 9 May 2003, Alex Rousskov wrote in "RE: AW: Using XML in OCP transport":
> I hope my answers will help you to finalize/voice your preferences.
Yes, thank you very much, Alex.
 
This is my vote:
 
 ICAP/1.1:       20%
 OCP/OCPTRAN:    65%
 OCP/BEEP:       15%
 
Reasons are a mix from all what I said and heard in this discussion so far.
 
Though I have my preferences: whatever we agree on from these three, I will help working on the protocol.

Regards
Martin

	-----Ursprüngliche Nachricht----- 
	Von: Alex Rousskov [mailto:[email-masked]] 
	Gesendet: Fr 09.05.2003 19:59 
	An: [email-masked] 
	Cc: 
	Betreff: OCP transport vote, commitment

	At the beginning of this discussion, my vote would have been: 

	        ICAP/1.1:        0% 
	        OCP/OCPTRAN:    15% 
	        OCP/BEEP:       85% 

	My current vote is: 

	        ICAP/1.1:        5% 
	        OCP/OCPTRAN:    55% 
	        OCP/BEEP:       40% 

	I would be willing to lead OCP/OCPTRAN development and probably can 
	have the first draft ready in 2 weeks or so. I would be willing to 
	lead OCP/BEEP development as well, provided BEEP experts such as 
	Marshall contribute a lot; I would expect first OCP/BEEP draft to be 
	available in a month or so. Finally, I would be happy to help with 
	ICAP/1.1 work, but I think ICAP experts such as Martin should lead 
	that activity. 

	Here is some justification of my current views. 

	* BEEP versus OCPTRAN: There are two issues for me here. Wheels reuse 
	  and XML scare. Initially, I thought that we should just go ahead 
	  and reuse BEEP. Reuse is great. However, as the discussion got 
	  more specific, I realized that there are two kinds of reuse. 
	  Let me call them black box reuse and white box reuse. 

	  Black box reuse is simple: you take existing something (protocol, 
	  library, whatever) and build on top of it using published 
	  interfaces. There is a clear boundary between the "reused" entity 
	  and its new "owner". In many cases, you can use or invent another 
	  something that can be reused instead, without modifying the 
	  owner much. Examples of black box reuse are: writing a C program 
	  (reusing C language and libc library), wget (reusing HTTP), reliable 
	  syslog (reusing BEEP) 

	  White box reuse is integration/merging with existing something 
	  (protocol, library, whatever) based on the knowledge of internal 
	  structure of that something. The boundary becomes less clear. 
	  In many cases, it is impossible to change the "reused" entity 
	  without also causing significant changes in its "owner". Examples 
	  of white box reuse: writing a Perl program using internal Perl 
	  datastructures for optimization purposes (reusing existing 
	  Perl datastructures), HTTP/1.1 (reusing HTTP/1.0), any protocol 
	  that defines its own BEEP message types (reusing BEEP) 

	  Black box reuse is great. White box reuse often, but not always, 
	  leads to long-term inefficiencies and wasted energy. "Clone and 
	  modify" is often better than white white box reuse, IMO. For 
	  example, I believe HTTP/1.1 folks made a strategic mistake by making 
	  HTTP/1.1 "semi-backword compatible" with HTTP/1.0 (and even having 
	  two conflicting RFCs for HTTP/1.1 itself!). It looks like ICAP 
	  suffered the same problem when migration from ICAP/0.9 to ICAP/1.0 
	  led to major ICAP vendors going different ways while offering 
	  relatively few advantages to justify the loss. 

	  In our case, OCP transport is border-line. We can, of course, 
	  use BEEP as a black box. The resulting protocol will be somewhat 
	  awkward to document and understand, but it will work (black box 
	  approach). We can also add our own message types to BEEP, yielding 
	  a more elegant design, but losing compatibility with existing 
	  BEEP libraries while still having to leave with certain BEEP 
	  features that cannot be simply "extended" (white box approach). 

	  BEEP folks say they saved the world by building something many 
	  working groups will reuse instead of writing specs from scratch. I 
	  agree. Unfortunately, BEEP is not universal enough (nothing 
	  is) -- it makes choices regarding message exchange patterns and 
	  channel negotiations that are not perfect for OCP. It requires XML. 

	  If we proceed with OCPTRAN path, we can (but do not have to) try to 
	  make a similar (but smaller scale) contribution -- future working 
	  groups might be able to reuse our protocol when what they do is more 
	  similar to OCP than to BEEP (efficient asynchronous bidirectional 
	  exchange of large number of opaque application messages that may be 
	  very small or very large). But that's probably too much to hope for. 

	* XML scare: 

	  Many people worry about XML in an "efficient communication" context. 
	  Perhaps my circle of life is too biased or too small, but that is my 
	  observation. To maximize OCP adoption chances (by ICAP community), 
	  we SHOULD NOT use XML (all other factors being the same, which they 
	  are not). We MUST NOT use XML for each application message exchange; 
	  using XML for connection-related negotiations MAY be OK, if we 
	  really need that kind of flexibility. 

	  Why do I care about ICAP community? Because if those folks do not 
	  migrate to OCP, OCP will probably die, and all our efforts will 
	  be wasted. 

	* ICAP/1.1 

	  Since we are so unsure about OCP transport, and since some belive 
	  that work minimization must be our top priority, polishing an 
	  existing and working protocol may be worse talking about. If we 
	  adopt ICAP/1.0 almost "as is" we can concentrate on other OPES 
	  aspects and, perhaps, make them slightly better. 

	  Migration for ICAP community will be simplified as well, especially 
	  if we make ICAP/1.1 100% backword compatible to ICAP/1.0. 

	Alex. 

	------------------------------------------------------------ 
	This mail has been scanned by wwsmtp.webwasher.com 
	(WebWasher 4.4 beta Build 499) 
	------------------------------------------------------------

---

From: Alex Rousskov <[email-masked]>
Date: Sat, 10 May 2003 22:51:57 -0600 (MDT)

All weighted personal preferences indicate that OCP/OCPTRAN is the
direction to go. Nobody has preferred any other option more.
Interestingly enough, the choice among ICAP/1.1 and OCP/BEEP options
is not clear. Several people value both options equally; some lean
towards the former; some towards the latter.

	ICAP/1.1  OCP/OCPTRAN  OCP/BEEP
	     0       100           0
	     5        75          20
	    20        65          15
	     5        55          40
	    25        50          25

There are two ways to proceed, I guess. We can propose to develop
OCP/OCPTRAN and wait for any objections until, say, Wednesday.
Alternatively, we can pressure other active members into making up
their minds (or asking more questions) until everybody has spoken.

Markus, Marshall, do you think we need more votes/comments? Should
we test for consensus regarding OCP/OCPTRAN now?

Thanks,

Alex.

P.S. If we had more active participants, we could try to do two
     "pilot" protocol drafts (OCPTRAN and BEEP), but it seems that we
     do not have the luxury of extra cycles and would have to decide
     while many factors are still not perfectly clear and some are
     not even known.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 May 2003 09:49:33 -0600 (MDT)

Let's try to see if there is consensus regarding proceeding with
OCP/OCPTRAN development.

I scanned the list archive to determine a group of "active
participants". If we include everybody who posted at least 4 e-mails
to the group mailing list in 2003, we get an "active" group of 9
people, generating about 640 e-mails. (For comparison, if we include
everybody who posted 2-3 substantive e-mails in 2003, we get about 14
people, generating about 652 e-mails.)

We know weighted preferences of 6 active participants out of 9:

            0        80          20
            5        75          20
           20        65          15
            5        55          40
           25        50          25

We do not know the opinions of the remaining three activists: Marshall
Rose, Markus Hofmann, and Reinaldo Penno. Guys, could you please voice
your current preferences?

If we hear no objections for the next 24 hours, let's consider the
issue closed and proceed with the OCP/OCPTRAN development.

Thank you,

Alex.

P.S. I do not mean to step on chairs' toes; I just want to make
     sure that we continue moving since everybody who spoke
     seem to prefer OCPTRAN. If I am making a procedural mistake,
     please step up and do whatever is appropriate to get us to
     a proper closure!

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 14 May 2003 11:24:28 -0600 (MDT)

Since there has been no negative remarks so far, I am going to start
adding OCPTRAN text to the OCP Core draft. I will post progress
reports and questions, as usual. If you do not think we should proceed
with OCPTRAN work, please speak up now and propose a way to reach
consensus on another transport.

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 14 May 2003 14:03:10 -0400

> consensus on another transport.

See my post from a few minutes ago. Looks like posts to this mailing 
list are delivered in batches with a several minutes of delay...

-Markus