On Tue, 6 May 2003, Martin Stecher wrote:
I agree to all of your assertions.
Martin,
Would it be fair to conclude, then, that your primary reason
for avoiding XML in OCP is assertion #7 (the use of XML will initially
alienate a noticeable fraction of the existing ICAP community)?
My reasoning is that if all of the performance-related assertions
below are true, then there is no performance problem with XML in OCP
context: all performance problems can be solved by practical,
real-world engineering. Such efforts are virtually always required to
support any new protocol efficiently anyway. If there are no
performance problems, then (based on you past postings), I assume your
primary concern is migration of existing ICAP community (i.e.,
assertion #7). Is my reasoning correct?
Thank you,
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?