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:[email protected]] Sent: Wednesday, November 25, 2009 11:34 AM To: [email protected] 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
