I like this idea of a "data" action. It is actually quite similar to a
license action, except that license are actually installed in the meta
data area too. I expect that a client would want to cache icons like it
caches licenses. The data icon could also provide a symbolic name for
the data so that the hash value isn't needed.
With a data action, maybe the set action for the icon could be
eliminated entirely. Just have a name=icon attribute on the data action.l
Regarding the processing, the manifest has to be loaded and parsed to
even know that there is a "set" action for a package icon (unless the
search interface is being used to retrieve that information). And if
search is being used, it can be used to get the hashvalue too.
IMHO, the use of hash values by pkg(5) should be kept as an
implementation detail and shouldn't show up in the interface (publishing
or client) at all.
Tom
Shawn Walker wrote:
Bart Smaalders wrote:
If you specify the icon by hash, the packagemanger is free to
cache it wherever it wants, and the publishers don't need to
care... and those of us using the command line won't need to
download the icons at all.
Except we don't currently support file actions that are payload only
as far as I know (i.e. the path attribute is a required attribute at
the moment). That leaves us with a few possible solutions (that I can
think of at the moment):
* enhance the file action to not require a path attribute and assume
such actions are payload only (this makes publication time
verification problematic and the fact that the path is treated as the
key attribute difficult)
* add a new 'data' action that is specifically for informational
payloads to be served by the depot server via /file/0, but are ignored
by client/imageplan as they are not intended to be installed to the
user's target system.
If we chose the second option, the pkg.icon attribute would then be
free to reference hash names of data or file actions (as
appropriate). That would also allow other, future attributes to
reference informational only payloads.
Thoughts?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
