Glenn Fowler <gsf at research.att.com> wrote:
> > This is a very similar issue to what applies to ksh93. Adding new code
> > without looking at portability creates a fork that make the software hard
> > to
> > maintain.
>
> just as ksh93 provides a user builtin/plugin api for extending ksh93
> I would recommend a plugin api for adding addtional archive formats to pax
>
> with judicious use of runtime .so plugins new archive formats could be
> supported without ever recompiling the pax a.out
>
> plugins could even handle closed source archivers by converting
> pax options to the closed source a.out options on the fly
> (e.g., a pax wrapper around zoo implemented as a plugin)
Such plugins are easy to write and to integrate if you use them in simple
unbuffered tar implementations only.
Star uses a buffered appraoach for optimized speed. Star's archiver process
does not know anything about "tape I/O" and star's "tape I/O" does not know
anything about archives. This may make it hard to define a plugin interface but
it makes it easy to keep tapes streaming or to copy directory trees in a fast
way.
In addition, star uses a lot of internal abstraction. If a plugin definition
takes care about these constraints, it may work but defining a useful plugin
interface is not simple.
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
