* John Rice <[email protected]> [2010-01-07 07:18]: > Peter Tribble wrote: > >On Wed, Jan 6, 2010 at 10:01 PM, Shawn Walker <[email protected]> > >wrote: > >>On 01/ 6/10 03:58 PM, Peter Tribble wrote: > >>>Won't users always want to use the short form? > >>> > >>>In that case, why inflict the hierarchy on the actual package names? > >>>Just use the basename as the package name, and it's what the user > >>>types, and is unique. > >>> > >>>Dropping the category hierarchy has some significant advantages: > >>> > >>> - It keeps the package names short and simple > >>> - there's a direct mapping between the user expectation and the > >>>package name > >>> > >>>Having the category as additional package metadata rather than part > >>>of the name would be a win in several areas: > >>The category ("classification") is already separate. Please don't confuse > >>package namespace with classification. > > > >I wasn't; but now I'm concerned. You're saying that there is both > >categorization and a namespace hierarchy? Either they match or > >they don't; and are either unnecessary duplication or causes of > >confusion. > > > It is really important to the GUI that we have some sensible way to > strip off redundant categorization information from the package > names, when displaying these packages in a Category a user has > selected. > > See: 9437 current multi-part name algorithm is goofy > > The only sensible way to do this with the current scheme is to make > sure that the first categorization metadata in info.classification > (allows for multiple classifications) matches the first portion of > the hierarchy name for that package. If it does we can strip it when > displaying the name if the user has clicked on a specific category.
I think you mean that the Package Manager will only use the org.opensolaris.2008 schema from the info.classification property. Right? I guess I don't see the need for a forced agreement: why wouldn't you take the list of packages in the selected category, and determine how much of the FMRI you need to display to make them unique? That is, if all of the final components are distinct, display only final components. If not, display one more component--either on all of the packages, or only on those in conflict. Repeat until no conflicting displays are present. Use tooltips to show the full FMRI if hovering. In one past discussion, some non-developer users wondered why we were emphasizing the FMRI/technical package identifier over the package description. Maybe we should focus on cleaning up the descriptions after a basic algorithm is available? > If they click on the All category we might choose not to strip them > at all of course. > > I think having to continue with the current special categories > approach is bound to fail in the long term. There are aspects of the special categories I would like to see moved out of info.classification, like those involving bundles, core/non-core, and potential notability, and into either separate properties or into the FMRI namespace (when relatively constant). - Stephen -- [email protected] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
