Date: Mon, 12 Apr 2010 12:07:13 -0400 From: Leinier Cruz Salfran <salfrancl.listas@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: make pkg_install suite reusable, please Message-ID: <k2qa2585ef1004120907w8e87f21cua0ef7ff1d0410e63@mail.gmail.com> In-Reply-To: <hptpq8$klh$1@dough.gmane.org> References: <x2ta2585ef1004090716vf74893dfo9d5412455294c64d@mail.gmail.com> <q2x3cb459ed1004090736t5a67f315geca1c199a5061e7d@mail.gmail.com> <alpine.BSF.2.00.1004111235330.80625@fledge.watson.org> <hptpq8$klh$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 11, 2010 at 8:34 PM, Marcin Wisnicki <mwisnicki+freebsd@gmail.com> wrote: > 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". =C2=A0This is particularly the cas= e for >> monitoring tools, where third-party applications have a lot of trouble >> parsing and tracking the output of tools like ps(1), etc. =C2=A0This 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 thin= gs > for free. It does not have to be XML with XML-Schema (though there are go= od > plaintext schema languages like RelaxNG-compact and you could possibly fi= nd > less verbose text encoding for XML). > > 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. > > The only problem I see is agreeing on a single format and forcing everyon= e > to use it. Which is probably why it will never happen :( > hello marcin that can be a smart solution but i prefer to use functions directly from library .. i think it's better well, alexander .. i must to follow your first suggestion: use 'pkg_*' commands (meanwhile) .. i plan to make this software usable to netbsd and openbsd too .. i'm not sure but maybe they have the same situation and for that reason i think use the commands is the way to follow i want to count on you to do more questions and surveys
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?k2qa2585ef1004120907w8e87f21cua0ef7ff1d0410e63>