Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Apr 2010 00:34:16 +0000 (UTC)
From:      Marcin Wisnicki <mwisnicki+freebsd@gmail.com>
To:        freebsd-hackers@freebsd.org
Subject:   Re: make pkg_install suite reusable, please
Message-ID:  <hptpq8$klh$1@dough.gmane.org>
References:  <x2ta2585ef1004090716vf74893dfo9d5412455294c64d@mail.gmail.com> <q2x3cb459ed1004090736t5a67f315geca1c199a5061e7d@mail.gmail.com> <alpine.BSF.2.00.1004111235330.80625@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Apr 2010 12:37:27 +0100, Robert Watson wrote:

> On Fri, 9 Apr 2010, Alexander Churanov wrote:
> 
>> 2010/4/9 Leinier Cruz Salfran <salfrancl.listas@gmail.com>
>>
>>> i want to ask you one thing: can you make the 'pkg_install' suite
>>> reusable .. means install 'libinstall.a' as a shared object in order
>>> to make it reusable by others devs
>>
>> I'd like to add my 50 cents. From my point of view, the true UNIX way
>> is re-using whole programs. This provides unbelievable isolation and
>> correctness. If you don't want to fork myriads of processes each
>> second, then, it's, probably, better to ask for pipe mode of pkg_*
>> tools. For example, aspell works that way. You start a process, write
>> commands and queries and read results.
> 
> While there are clearly benefits to process isolation, there are
> countless situations in UNIX where I've said to myself "Oh, I wish I had
> a lib<foo> not just a <foo> command".  This is particularly the case for
> monitoring tools, where third-party applications have a lot of trouble
> parsing and tracking the output of tools like ps(1), etc.  This is why
> recently we've been working on libmemstat(3), libprocstat(3),
> libnetstat(3), etc -- so that tools can avoid rewriting that code as
> well as avoid the parsing problem.

A middle-ground solution to this is to standardise on a common data
exchange format with a schema definition language. With schema you can
autogenerate high level parsers and generators, validators and other things
for free. It does not have to be XML with XML-Schema (though there are good
plaintext schema languages like RelaxNG-compact and you could possibly find
less verbose text encoding for XML).

Fine human readable competitors to XML exists like OGDL, YAML or JSON.
OGDL project even have patches for OGDL output in GNU utlities.

If, say ps or ipfw, had a switch like '--format-output-yaml' and
'--print-output-schema' (alternatively schema files could be stored
somewhere in $prefix/share) it would be trivial to use them anywhere.
Similar approach could be adopted to input passing with possibility of
pipe mode. Any utilitily, with mere tweaks to output formatting and
pipe mode would in fact be a class that you could instantiate (run)
and use like any other object in your programming language and all of
that for free, autogenerated from schema descriptions ;)

The only problem I see is agreeing on a single format and forcing everyone
to use it. Which is probably why it will never happen :(




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?hptpq8$klh$1>