On Thu, 8 May 2003, jfcm wrote:
I suggest we put that on an exell table (I can do that, but may be
you are more informed) and to keep an HTML page on it on the site. I
am not technically good enough to understand everything in here (I
am here to make sur my needs are covered and to learn how I could
cover them should them not to be met).
I could render the lists below in HTML, but I would like to hear
others feedback first. It seems to me that we should be ready to make
a decision on OCP transport now -- all these points have been
discussed already. I am OK with more clarification and discussion if
needed, of course, but I want to avoid spending time on documentation,
especially if others do not find this useful and need something else
to select the "best" OCP transport.
But I feel there may be other points and I understand this is seen
from the OCP developper point of view, not so much yet from the
developper having to use OCP point of view? jfc
I am sure there are other points. These biased lists are based on two
points of views: OCP author and OCP/ICAP implementor.
Alex.
P.S. I would rather not do an Excel spreadsheet because I do not
usually use Microsoft products.
At 06:25 08/05/03, Alex Rousskov wrote:
Polished ICAP/1.1:
- OCP stays application specific (though we may be able
to hack SMTP support, in since real implementations already
do that now)
- less OCP work for us
- little incentive to upgrade existing ICAP installations and
implementations
- very easy migration
- implementation complexity comparable to ICAP/1.0
- no XML worries
New ICAP/2.0 on top of TCP:
- OCP becomes the best protocol we can come up with, fixing
known ICAP problems or limitations
- more OCP work for us
- more incentive to upgrade existing ICAP installations and
implementations
- preserves original ICAP look and feel to ease the migration
- implementation complexity somewhat higher than of ICAP/1.0
- no XML worries
- some pummeling from IETF powers for not reusing BEEP?
OCP on top of BEEP:
- OCP fixes known ICAP problems or limitations
- some tension between BEEP and OCP transport needs will
be visible in protocol design and may limit BEEP library
reuse (but we do not expect much code reuse anyway)
- less work for us when it comes to transport security
negotiations and such (BEEP community already did that)
- more incentive to upgrade existing ICAP installations and
implementations
- more difficult migration path
- high implementation complexity
- XML worries
- kudus from Marshall and IETF powers for reusing BEEP?