On Thu 05 Mar 2009 at 01:54PM, Brock Pytlik wrote:
> >>So before I dig in too deeply, is this work at all obviated by, or
> >>changed by, Bart's upcoming manifest caching work? It sort-of seems to
> >>me like all of the information needed by "info" could simply be cached
> >>in a "manifest.info" file which had exactly the required information in
> >>it; this would seem to sidestep the need to classify what is "fast"
> >>to get versus what is "slow" to get.
> >>
> >> -dp
> I'm not sure, I wrote this back before I'd heard about Bart's manifest
> caching stuff. Right now, the gui doesn't use manifest caching at all.
> I'll touch base with Bart and find out whether this will fix all of
> those issues or not.
Brock and I touched base with Bart on this and concluded that
this work is still important, since the distinction of fast
vs. slow is really about what's in RAM versus what's on disk.
My high level comment is that FAST_OPTIONS and SLOW_OPTIONS seems
to bind interface too much to implementation.
I would recommend defining:
BASICS, SUMMARY, CATEGORIES, STATE, PREF_AUTHORITY, SIZE, LICENSES
LINKS, HARDLINKS, FILES, DIRS, DEPENDENCIES
And defining ALL and ACTION_OPTIONS. It seems to me that
the rest could be obviated without too much pain to the caller--
ALL_BUT_LICENSE for example to me seems cumbersome.
I might be tempted to call BASICS something like FMRI, or IDENTITY
or something.
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
