ietf-openproxy
[Top] [All Lists]

RE: AW: Using XML in OCP transport

2003-05-07 09:10:44


On Wed, 7 May 2003, Martin Stecher wrote:

My concern is that OCP will not be successful, if implementors don't
like it or find it too complicated or too much work to implement. So
yes, my primary reason is #7. But regarding new potential
implementors it is more an issue of assertions #2 and maybe #6,
meaning that an OCP implementation which takes it serious needs
fully compliant XML support.

For example: ICAP support in the Squid proxy added less than 1500
lines of code. Any idea what it will take to get OCP/BEEP into
Squid? As far as I know there is no XML support in Squid yet.

I would think it would take about the same 2000 lines, provided an
existing XML and BEEP Core libraries are used and no session
encryption is required. If Squid folks decide to optimize an XML
parser for OCP, it would probably take another 500 lines, provided an
inefficient XML library is still used for unexpected cases.

While I have not seen any, I am not optimistic that an existing BEEP
Core C++ library would satisfy Squid performance needs. In fact, I do
not see any available open/free BEEP library in C++ on beepcore.org.
For reference, a permaBEEP library has about 30,000 lines of Java
code. I suspect that a decent native BEEP implementation in Squid
would be 7,000 lines or less (without encryption support).

I agree and never said that BEEP is not efficient. I am not
concerned about our own implementation although it will probably be
somehow tricky to have an optimized XML parser for OCP and still
passing the compliance test that probably/hopefully The Measurement
Factory will come up with ;-)

You can always take the lazy approach: an optimized XML parser for
simple/canonical/expected cases and a slow XML library for anything
else. The optimized parser would just have to be smart enough to know
when its input is not a "simple/canonical/expected" case.

But evangelising others that this protocol is definitly the one they
should use or migrate to, this task could be a little harder to me.
That's my concern.

I agree. I wonder how we should decide which way to proceed. What is
better:

  - best fit: a simpler, compact, domain-specific transport that
    we have to write (OCPTRAN), increasing OCP adoption chances

  - fast result: a more complex, larger, general-purpose transport
    that we can reuse with some effort and loss of elegance (BEEP),
    decreasing OCP adoption chances

I have a feeling that if "fast result" is the correct choice here,
then we should just polish ICAP instead of doing OCP. On the other
hand, if "best fit" is the way to go, then I am worried about
documenting security negotiations (something BEEP already has).

Alex.



     1 An OCP/BEEP implementation would parse simple,
       short XML fragments most of the time.

     2 To be compliant, an OCP/BEEP implementation would
       have to be able to parse arbitrary XML, including
       malicious XML.

     3 In 7 years, virtually every OCP/* agent will support XML
       for reasons unrelated to transport; that support may not
       be efficient (e.g., parsing of configuration files or
       generating logs).

     4 It is possible to optimize parsing of simple,
       short XML fragments with known parsing goal
       (e.g., just to find the profile URIs and ignore
       everything else).

     5 It is possible to optimize generation of simple,
       short XML fragments.

     6 It is very tempting to use XML for OCP negotiations
       and other, mostly performance-unrelated OCP tasks _if_
       XML has to be supported for transport reasons anyway.

     7 The use of XML will initially alienate a noticeable
       fraction of the existing ICAP community

Does anybody disagree with any of the above assertions?