I agree with everything you are saying except that I think there is
value from
a simple C++ interface of just abstract classes with virtual functions and
perhaps a few exposed instance variables for very stable common objects.
The reason is that the internals are modeled that way and most plugins will
be written in a language which supports at least basic OO features and
can be mapped using an automatic tool like SWIG.
Of course good copyable examples are critical. One reason I am bringing
this up is that some of the best examples are builtin and written against
the internal C++ API which makes them harder to use as templates for
the external C API.
I agree that FULL C++ is a world of pain in terms of complexity and
compatibility and on balance not worth it.
john
Belmon, Stephane wrote:
Maybe it depends what kind of plugins you're talking about.
Simple header munging (a la output-header.c) is simple(-ish)
almost no matter what; boilerplate is boilerplate. Realistically,
people will just cut & paste from samples (thanks Chris).
A really complex plugin -- say, analyze the payload as it comes
along, using *remote* services to do so, creating a bunch of
new VIOs etc. -- is a completely different animal. Maybe
it would benefit from a lot of help from the API. It's
arguable whether people would actually go down that path; if
the protocol to that remote service isn't dead simple, you'd really
like to use an existing library to speak it, which is not going
to play well with the TS infrastructure.
It also really depends what is meant by "a C++ API".
C semantics with syntactic sugar isn't earth-shattering, but you
also don't get all that much from it (forgot to unlock/release/
reenable before return? Tough.) Full-on C++, where API methods
regularly throw, expect auto_ptrs and return STL containers...
that's a whole different beast. And so is one which provides
stdlib "equivalents" (a common style).
Either way, documentation and good examples probably trump
architecture.
It would be really interesting to see other languages (non-C/C++)
supported, if only for one reason: there would have to be
some "easier paths" (making performance tradeoffs), usable
from C/C++ as well.
-----Original Message-----
From: John Plevyak [mailto:jplev...@acm.org]
Sent: Wednesday, November 25, 2009 11:34 AM
To: trafficserver-dev@incubator.apache.org
Subject: Re: C++ version of InkAPI ?
Given that the existing C API is often a wrapper on an internal C++ API,
there is a natural
mapping of just using the existing internal C++ APIs as the InkAPI but just
convert them to be pure virtual. This would also encourage clean internal
APIs to make it easier to use for the InkAPI. I am not sure about the
whole setter/getter
vs exposing some stable data structures vs smarter higher level
interfaces, but perhaps
these are better considered on a case by case basis.
Doing internal C++ to external C then wrapping the external C with
external C++ is going
to result in a lot of code to be maintained unless we can automate it in
some way. But
if it is automated then perhaps we can automate a native extern C++
interface as well.
But if it is automated then why not just use SWIG to do the automation
and why not just
use SWIG to automate the external C from the C++ which we have an
internal version of already?
Anyway that was the train of logic I went down.. of course it becomes
more tenuous the
farther you follow it, but it is still interesting to consider.
john
Leif Hedstrom wrote:
On 11/25/2009 11:43 AM, John Plevyak wrote:
<< transfer from IRC>>
Here is a proposal:
1. C++ APIs
2. Clean SWIG for supporting other language
(in other words, the C++ APIs would have to work well with SWIG)
Open question: do we expose some very stable data structures, e.g.
IOBuffer, VIO ?
So, what exactly would change in the APIs? Are we going all out OO,
and everything becomes class methods, getters/setters etc.? If we do
this, we should do an equally drastic redesign of the Remap APIs (and
no more struct passing etc.).
As an alternative, how much worse would it be to have a low level C
API (that we expose) like today, and then make a higher level object
oriented API that wraps the C APIs?
For sure, now is the time to do any major changes like this :).
-- Leif
Protected by Websense Hosted Email Security -- www.websense.com
