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 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.
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?
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 ;-)
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.
Regards
Martin
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?