Danek Duvall wrote:
In a grand tradition, I'm not actually proposing a solution. However, for
a specific example, I see p5i.parse() and the loops on lines 109 and 118,
and think -- the only difference between these two loops is that the first
loop handles single-valued attributes and the second loop handles
list-valued attributes. Given that in repositoryconfig.py you define each
attribute's type (as single or list valued, among other things), then you
could use that information here to eliminate the need for two loops. Just
iterate over all the attributes you get, ignore ones you know nothing
about, and pull in the remainder based on their type, not on their name.
If you follow this train of thought, it leads you to having a single place
where all the attribute metadata is defined, and a handful of places where
the attributes are managed, consuming the attribute metadata so that,
again, you know what to do with an attribute generically -- based on its
metadata, not on its name. Certainly that won't extend to everything, but
it looks like the bulk of the attributes could be handled like that.
I'll have to think on this some more. As I said before though,
eventually a .p5i file will just be stored in a repository and the api
can be used to parse the file and a publisher object will be returned
thereby removing the need for any of this knowledge at all.
Nothing consumes any of these attributes yet, right?
Which attributes?
"prefix" and "alias".
They're used by the client api, which technically supports both. Though
I haven't exposed alias to the cli yet.
Also, refresh_seconds isn't a text attribute; it's a numeric attribute.
I don't see how that matters, other than I'd said "text attribute"
originally. Take "registration_uri" instead, if you prefer.
If you mean "attributes in general", yes, after the publisher metadata
gets moved to a .p5i file, I can rename the remaining attributes
(whatever few exist) to using '-' instead of '_'.
Well, I'm not the one "writing the file" in this case.
You may not be "writing the file" but you absolutely are in control of the
output surrounding the blob that the json module writes. That module
doesn't output a newline when it's done, but the complete output of the
operation should include a terminating newline, which means it's up to the
code called after the json module is done to emit that newline.
Filed bug 9027.
There will only be one publisher per repository as far as I'm aware.
Am I simply misremembering the meetings we've had where we've explicitly
talked about this desire? Perhaps I am. At any rate, you did say "p5i
file*s* in the repo", so maybe the plural was unintentional, or maybe I
don't see why you'd want more than one p5i file per publisher.
I probably mispoke. I know we've talked about having multiple p5i files
on the client-side though, and eventually we will have multiple
repositories for each depot with each repository having its own p5i file.
My other thought was that this information is metadata about the repository
and doesn't belong in SMF. SMF should only be used to configure the
*depot* server itself since that is the server it is managing.
Okay, that's a fair distinction, though not necessarily a clear one. There
are attributes stored in SMF right now that appear not to be depot related,
for instance. Maybe that's just a bug that needs to be cleared up, and
some attributes shuffled around. But for some of the really basic ones,
like "name" or "description", they can be used in a bunch of different
places -- name of the service advertised by mDNS, name as plastered on the
web pages, name as served up to the pkg client via publisher/0. It's not
clear to me whether "name" then is an attribute of the depot or the
repository.
You are correct that a lot of things need to be shuffled around.
However, other than the feed configuration and the maintainer
information recorded in the cfg_cache nothing else is fairly static.
I don't really view the publisher metadata as configuration to be managed
so much as metadata much like the package metadata that exists in the
repository.
It's data; it needs to be managed somehow, unless you consider it to be
fixed. Perhaps the publisher data will be, but the repo data likely will
not.
Parts of the repository data will not be fixed, but most of the
publisher data and most of the repository data should be relatively fixed.
My personal belief is that managing multiple repositories for a single
depot plus all the repository and publisher metadata would be a mess as
opposed to just having a simple text file that could be edited.
Especially since that simple text file will have to exist anyway.
Still, as far as I'm aware, most of the configuration aspects of a depot
are supposed to be in SMF, but then "cached" in the cfg_cache for the
depot. But maybe that has changed since the original design document
was written.
I'll have to get back to you on this particular issue.
Thanks for taking the time to respond,
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
