On Sunday 13 May 2001 23:57, you wrote:

1. Selector -- a selector will have exactly one configurable parameter: an array of things which conform to the server interface, and an array of things which conform to the delayed interface

I have to apologise for my design here. We ought to be pickling (jellying? ^_^) ServerSets, not Selectors. (After all, a GTK selector is a different class than a regular selector, which means it's not possible to read in a selector to a GTK app, or merge two selectors together, without some hackery.) Also, "Selector" conjures up images of Smalltalk and Objective C which are wholly inappropriate, as I was not aware of that use of terminology when I named it :) So, to break down this use-case further, a user wishes to configure a set of servers. They can perform one of 4 actions (keep in mind I'm thinking from the user/UI perspective, *not* the perspective of the actual config system code) * view a list of servers currently in the set * add a server to the set (this is a big one) * remove a server from the set * configure a server in that set these correspond roughly to operations on dictionaries (assuming that ServerSets ; roughly, -------- for servername, server in serverset.items(): display(servername, server) ---- newServer = somehowCreateAServer() servers[newServerName] = newServer ---- del servers[someServerName] ---- foo = servers[someServerName] doConfiguration(foo) --------

2. POP3 Server -- (optionally) a name, a port and something that conforms to the "dictionary" interface (.has_key, [], .get which are consistent) where the keys are strings, and the values are things that conform to the domain interface, and to the POP3 domain extensions (authenticateAPOPUser)

I think that we're saying similiar things here, again -- dictionary operations.

3. DomainDictionary -- contents, a mapping of strings to things conforming to the domain interface

Again, a dictionary...

4. MaildirDbmDomain -- add a user/password, remove a user, change a password

Looks similiar again, "change a password" being similiar to "configure a sub-element"... presumably when we have more kinds of users (e.g. the "run a shellscript" variety) this will be different. Presumably a User is a username/password combo (changing the username may require some monkeying, since that's also the key that it's stored in the domain as); but may be arbitrarily complex, as users do more complex things (frex, a web-story-posting interface through email).

5. HTTPServer -- something conforming to the resource interface

This again will probably need some restructuring. Shouldn't inherit from TCPServer, etc. So "add/remove a port to listen on" will probably be an additional case.

6. FolderResource -- a mapping of strings to resources, and all those of DataResource

I don't see any reason why all of them have to be DataResources...? "Any non-abstract subclass of Resource" seems more reasonable.

7. DataResource -- code (an int), headers (a mapping of strings to strings) and the data (a long-string)

I think we're missing FileResource. That encompasses a few other things (a mapping of file extensions to MIME-types and processor resources, for example), but again, that's just another hash of either strings or classes.

8. TelnetServer -- username, password

Finally, a simple form interface, alone :) Most of the things that we're talking about here have either an interface that specifies some attributes (e.g. a dictionary with a fixed set of string keys) or a dictionary which, as far as these cases are concerned, is always keyed by strings, and may have values which are either strings, classes, or instances of some fixed part of the inheritance (whether through __bases__ or __implements__) heirarchy, rooted at a particular class (or interface). So, having contributed what I can to the discussion of use cases -- I don't see that the previous proposal solves this issue in an elegant way; it seems like all the things here that require a "dict" parameter are not well-served by the getParameters/setParameter interface; the app code will have to decompose a "set" of the DictParameter in question by doing a comparison of what was there before and what is there now, into a set of add/remove operations (in, I might add, indeterminate order). Since most of both of our examples were these sorts of things, it doesn't seem well optimized for the common case; although I believe I'm missing something. -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph