RFC. Suggest that Perl XS is a way to enhance plugin portability, ease porting burden.

Stanley Hopcroft Stanley.Hopcroft at IPAustralia.Gov.AU
Mon Nov 25 10:10:05 CET 2002


Dear Ladies and Gentlemen,

I am writing to request your comments on a potential means of

 . increasing the portability of important plugins

 . reducing the cost of porting/configuring some plugins.

Recently, I attempted to use Mr Galstads admirable check_dhcp
plugin from the contrib directory of Nagios/Netsaint (N/N).

It came as a blow to realise that porting it from Linux to FreeBSD (for
me) may have cost as much as rehacking it (the Linux includes for
ethernet devices are different and there are some nasty FreeBSD include
order bugs to deal with at least).

It also occurred to me that this same portability factor is inhibiting
the publication of other plugins that may do good stuff (like simulating
an M$ 9x [not NT/2000] logging onto a domain].

A potential solution for all these problems is to use Perl XS as a
portable way of accessing standard libraries (or near standard) such as
libsmb and libdhcp.

In this way,

. one gets C like performance from a Perl harness (strengths of both C
and Perl)

. the portability problem is largely solved by the Perl MakeMaker tool
set (I think)

. one gets a much more robust way of writing plugins than the usual
plugin approach of forking (with backticks) a userland app (such as
nmblookup or smbclient) and reading its output.

Among the many bad things about that approach are

. the portability program is at least as bad as C (since you have to
find out where optional distribution such as Samba are stashed)

. many such apps fail to set return codes usefully: one is forced to
read the app output and this can be __so__ variable.

. often the userland interface is inconvenient or inefficient (eg
reading the last records with smbclient forces you to read __all__ the
file. Reading a descriptor lets one use read with an offset directly at
the eof).

. it requires a fork + exec.

Of course, there are problems with this approach too, notably it becomes
so much harder to write plugins since XS is so much harder than both C
and Perl.

Maybe a compromise is that someone steps up to write Perl XSs that
exposes the key functions in some vital libraries for plugin writers to
call.

Candidate libs include

. libfetch

. libdhcp

. libsmb

After these are written and the Perl interface is made public and
published in some supplement to the plugin guidelines, developers could
use the resulting greatly simplified Perl interface to do the same
things as are normally done (with far more pain) in C.

Maybe these XSs already exists.

Yours sincerely.

-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf




More information about the Users mailing list