[Twisted-Python] configuration usecases
![](https://secure.gravatar.com/avatar/faeb19fbb879e56c1be4a300cfd80ec8.jpg?s=120&d=mm&r=g)
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 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) 3. DomainDictionary -- contents, a mapping of strings to things conforming to the domain interface 4. MaildirDbmDomain -- add a user/password, remove a user, change a password 5. HTTPServer -- something conforming to the resource interface 6. FolderResource -- a mapping of strings to resources, and all those of DataResource 7. DataResource -- code (an int), headers (a mapping of strings to strings) and the data (a long-string) 8. TelnetServer -- username, password -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Sunday 13 May 2001 23:57, you wrote:
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) --------
I think that we're saying similiar things here, again -- dictionary operations.
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.
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
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Sunday 13 May 2001 23:57, you wrote:
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) --------
I think that we're saying similiar things here, again -- dictionary operations.
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.
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
participants (2)
-
Glyph Lefkowitz
-
Moshe Zadka