[Top] [All Lists]

RE: OCP transport vote, commitment

2003-05-10 13:54:53

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.


        -----Ursprüngliche Nachricht----- 
        Von: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
        Gesendet: Fr 09.05.2003 19:59 
        An: ietf-openproxy(_at_)imc(_dot_)org 
        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. 


        This mail has been scanned by 
        (WebWasher 4.4 beta Build 499) 

<Prev in Thread] Current Thread [Next in Thread>