On Tue, May 19, 2009 at 11:52:56AM -0500, Shawn Walker wrote: >> Again, the problem is that you have three different places you need to >> go to enhance these data structures, without any guidance as to what >> kind of changes you need to make in each (and that assumes you actually >> know about all those places in the first place). I'd strongly recommend >> finding a way to encode all the data you need to know about each of the >> attributes in a single place, so that all consumers need only look at >> the attribute metadata to decide how to manipulate the attributes. > > I'm not sure how to accomplish that. First of all, consumers of the > object can't just blindly get a list of the attributes of an object and > then expect to pass them into the object constructor. Second, depending > on how those consumers store their data to construct the object, they may > need to alter or otherwise massage the data into a format appropriate for > constructing the object. > > Finally, I would note that the pkg.client.publisher module has a note > about the fact that it is considered part of the client api and that any > changes to it have to be documented, and any relevant consumers updated.
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. >>> Furthermore, the name is really the "prefix" of the publisher (such as >>> opensolaris.org or org.opensolaris) and the alias is a short name that >>> the user will choose. >> >> Okay. I thought we were going to move to uuids for canonical identifiers, >> provide suggested user-friendly names for them, but allow people to name >> them as they wished. > > I'm not aware of it; but you're more in the loop than I am. No, I don't think so. >> Nothing consumes any of these attributes yet, right? > > Which attributes? "prefix" and "alias". >>>> Can we switch to using dashes instead of underscores for text >>>> attributes? >>> Huh? >> >> For example, "refresh_seconds" -> "refresh-seconds". > > Are you talking about the repository configuration file? What else? > I didn't do that because "+" and "-" are not allowed in variable names in > Python. So? Do the attribute names have to have the same names as python variables? I didn't see where that was done. > I know that the repository configuration file itself might allow it, but I > guess I'm lost as to the purpose here. I hate underscores. I'm struggling to get rid of them in the manifests, and I don't want them cropping up in other places if I can possibly help it. > 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. > I'm really confused now... As am I. I've no idea if I'm speaking English anymore. >>>> A couple of bugs in the test server: >>>> >>>> - http://ipkg.sfbay.sun.com:8009/publisher/0/ gives me a file that has >>>> no terminating newline. >>> I didn't add one and json.dump doesn't add it. Should it? >> >> I don't know whether it should or not, but if you know that the stream >> is over, you should make sure that there's a newline at the end. If >> that's written to a file, it won't have a terminating newline, and that >> just tends to be a pain in the ass. > > 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. > I'll open a bug if that's what you want. It would have been nice to have had it in the first wad, but yes please, file a bug. >>> However, my long-term goal is to eventually just store .p5i files in the >>> repository for the publisher and repository metadata and not have the >>> information in the cfg_cache at all. >> >> So each publisher would be represented by a p5i file in the depot config >> directory, and the depot would read both those and the cfg_cache file? > > 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. > 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. > 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. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
