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>