[Twisted-Python] configuration usecases

Glyph Lefkowitz glyph at twistedmatrix.com
Mon May 14 03:03:02 EDT 2001

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 

 * 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]

> 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 

> 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

More information about the Twisted-Python mailing list