[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AW: Using XML in OCP transport
I set-up my credibility filter to the support of DNS value added services.
Obviously XML does not fit the job. There may be different support however.
But was it expected is a lean, simple, stuff, robust and secure. Most of
the initial aplications will be security. Where the flow will be authorised
to go across, or will be trown away. Then it will probably be URL
conversion (payment gateways could use that).
At 10:21 07/05/03, Martin Stecher wrote:
> 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
> Thank you,
> > > 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?
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.474 / Virus Database: 272 - Release Date: 18/04/03