From: Geoffrey T. <gta...@na...> - 2001-12-10 14:13:09
|
At 07:21 PM 12/9/01 -0800, Chuck Esterbrook wrote: >Woops. In case, you were wondering, here are the rel notes: > >- 0.6.1 changes > All bug fixes: > - WebKit > - "File" is the new default session store, since > "Dynamic" has >concurrency issues. File also has some tricky concurrency issues, mentioned in the comments to SessionFileStore.__setitem__(). If two servlets simultaneously modify the session, one change wins and the other change is lost. Whereas Memory works perfectly and is significantly faster, especially if you're storing lots of data in sessions. I vote for making Memory the default until we fix the Dynamic store. And we ought to document the problems with the File store somewhere other than in the comments. > - The webkit unix init script > - now works with args "stop" and "restart" > - works on non-RedHat systems > - removes the pid file upon shutdown > - MiddleKit > - Certain situations could lead to invalid object > references in the >SQL database, thereby disconnecting the two objects. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Chuck E. <Chu...@ya...> - 2001-12-10 18:24:49
|
On Monday 10 December 2001 06:14 am, Geoffrey Talvola wrote: > File also has some tricky concurrency issues, mentioned in the > comments to SessionFileStore.__setitem__(). If two servlets > simultaneously modify the session, one change wins and the other > change is lost. Whereas Memory works perfectly and is significantly > faster, especially if you're storing lots of data in sessions. > > I vote for making Memory the default until we fix the Dynamic store. > And we ought to document the problems with the File store somewhere > other than in the comments. I thought Memory didn't work with OneShot very well and therefore was poor for development. Is that no longer true? -Chuck |
From: Geoffrey T. <gta...@na...> - 2001-12-10 19:49:28
|
At 10:24 AM 12/10/01 -0800, Chuck Esterbrook wrote: >On Monday 10 December 2001 06:14 am, Geoffrey Talvola wrote: > > File also has some tricky concurrency issues, mentioned in the > > comments to SessionFileStore.__setitem__(). If two servlets > > simultaneously modify the session, one change wins and the other > > change is lost. Whereas Memory works perfectly and is significantly > > faster, especially if you're storing lots of data in sessions. > > > > I vote for making Memory the default until we fix the Dynamic store. > > And we ought to document the problems with the File store somewhere > > other than in the comments. > >I thought Memory didn't work with OneShot very well and therefore was >poor for development. Is that no longer true? > >-Chuck Hmmm, I guess you're right. Looking at SessionMemoryStore.py, it appears that it doesn't load and save session data if the appserver is non-persistent. If we removed the checks of isPersistent in SessionMemoryStore.py, I think it would work fine with OneShot.cgi. I'm not really sure why those checks are there -- all they seem to do is make it impossible to use the Memory store with OneShot.cgi. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Tavis R. <ta...@ca...> - 2001-12-10 20:49:00
|
Geoff, going back to your class-based config syntax... The reason we'd need to subclass SettingsContainer is that it is possible to have settings that are in fact classes and don't begin with an underscore: ## from SettingsManager import SettingsContainer as SC class Applications(SC): class MyApp(SC): class Dirs: # virtual dirs like <location> in Apache Services = '/home/tavis/MyApp/Services' Products = '/home/tavis/MyApp/Products' from Foo import Bar as ApplicationClass from Foo import Whiz as RequestClass from Foo import Bang as SessionStoreClass ## Without using something like SettingsContainer those custom classes would be treated as if they were SettingsContainers themselves, which is definitely not what we want in this case. There is another alternative: create a slightly modified Python syntax that uses a different keyword than 'class' for SettingsContainers. A custom import_hook (via the standarde ihooks.py module) would be used to import the config modules: ## config Applications: config MyApp: config Dirs: # virtual dirs like <location> in Apache Services = '/home/tavis/MyApp/Services' Products = '/home/tavis/MyApp/Products' from Foo import Bar as ApplicationClass from Foo import Whiz as RequestClass from Foo import Bang as SessionStoreClass ## Once the import hook has been loaded, "import WebkitConfig" would find WebkitConfig.cfg, translate it to the syntax in the first example above and then load it as if it were WebkitConfig.py. To WebKit and the end user it would be seemless. We could even get rid of the keyword completely: ## Applications: MyApp: Dirs: # virtual dirs like <location> in Apache Services = '/home/tavis/MyApp/Services' Products = '/home/tavis/MyApp/Products' from Foo import Bar as ApplicationClass from Foo import Whiz as RequestClass from Foo import Bang as SessionStoreClass ## The advantages would be: * it's very concise * ALL other Python syntax would work as expected (even class) * no need to use the 'class' keyword, which is misleading in this situation * the experienced gained working with the import hooks here would transfer to Cheetah and other Webware components that need to build servlet factories that load a customized Python syntax The disadvantages would be: * it would require bit of work * we would have to be careful not to create clashes with other import hooks, such as the ones used by ZODB. Quixote uses the technique to load its .ptl template files. Their custom import hook module is 152 lines long including comments, so it doesn't look very difficult. In dictionary format these settings would be expressed as: ## from Foo import Bar as ApplicationClass from Foo import Whiz as RequestClass from Foo import Bang as SessionStoreClass Applications ={'MyApp':{'ApplicationClass':ApplicationClass, 'RequestClass':RequestClass, 'SessionStoreClass':SessionStoreClass, 'Dirs':{'Services':'/home/tavis/MyApp/Services', 'Products':'/home/tavis/MyApp/Products', } } } ## Either format would be valid and you would be able to mix the two where necessary: ## from SettingsManager import SettingsContainer as SC class Applications(SC): class MyApp(SC): Dirs = {'Services':..., 'Products':..., } from Foo import Bar as ApplicationClass from Foo import Whiz as RequestClass from Foo import Bang as SessionStoreClass ## Internally Webware would store all settings as dictionaries. Tavis |
From: Geoffrey T. <gta...@na...> - 2001-12-10 21:10:44
|
At 01:59 PM 12/10/01 -0800, Tavis Rudd wrote: >Geoff, >going back to your class-based config syntax... > >The reason we'd need to subclass SettingsContainer is that it is >possible to have settings that are in fact classes and don't begin >with an underscore: > >## >from SettingsManager import SettingsContainer as SC >class Applications(SC): > class MyApp(SC): > class Dirs: # virtual dirs like <location> in Apache > Services = '/home/tavis/MyApp/Services' > Products = '/home/tavis/MyApp/Products' > from Foo import Bar as ApplicationClass > from Foo import Whiz as RequestClass > from Foo import Bang as SessionStoreClass >## It seems very odd to me to have a value in a config file be an actual class object. I was expecting settings to be things like ints, strings, lists, dictionaries, tuples, etc. but all basically constants that didn't depend on code. I would propose that to specify a class as a config setting, you would specify a string like "Package.Module:Class" where you can leave off the ":Class" part if the class name is the same as the module name. PSP uses this convention for importing stuff and specifying base classes. So your example would be: class Applications: class MyApp: class Dirs: # virtual dirs like <location> in Apache Services = '/home/tavis/MyApp/Services' Products = '/home/tavis/MyApp/Products' ApplicationClass = 'Foo:Bar' RequestClass = 'Foo:Whiz' SessionStoreClass = 'Foo:Bang' The advantage is that you can import the config file without having to actually import the class. Perhaps you're just running a config file pretty-printing utility, and you don't want it to have to actually do the import. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Tavis R. <ta...@ca...> - 2001-12-10 21:28:55
|
On Monday 10 December 2001 13:11, Geoffrey Talvola wrote: > At 01:59 PM 12/10/01 -0800, Tavis Rudd wrote: > >Geoff, > >going back to your class-based config syntax... > > > >The reason we'd need to subclass SettingsContainer is that it is > >possible to have settings that are in fact classes and don't begin > >with an underscore: > > > >## > >from SettingsManager import SettingsContainer as SC > >class Applications(SC): > > class MyApp(SC): > > class Dirs: # virtual dirs like <location> in Apache > > Services = '/home/tavis/MyApp/Services' > > Products = '/home/tavis/MyApp/Products' > > from Foo import Bar as ApplicationClass > > from Foo import Whiz as RequestClass > > from Foo import Bang as SessionStoreClass > >## > It seems very odd to me to have a value in a config file be an > actual class object. I was expecting settings to be things like > ints, strings, lists, dictionaries, tuples, etc. but all basically > constants that didn't depend on code. That is part of a fundamental shift I'm proposing. If you use Python for configs, why not fully exploit its capabilities? If the settings are all constants strings then you are only using Python for its pretty syntax. I'm interested in both the syntax and the dynamic features of Python. Specifically, I want to be able to load either constants, classes, or live pre-initialized objects into WebKit. Consider this example: ## from WebKit.Application import Application class MyAppClass(Application): # define some custom stuff that allows collaboration # between two otherwise separate applications, such # as doing some complex request chaining _myApp = MyAppClass('MyApp') _partnerApp = MyAppClass('PartnerApp') _myApp.setPartner(_partnerApp) AppServer: Applications: MyApp = _myApp PartnerApp = _partnerApp ## I don't think this sort of magic will be common, but it should be possible. > I would propose that to specify a class as a config setting, you > would specify a string like "Package.Module:Class" where you can > leave off the ":Class" part if the class name is the same as the > module name. PSP uses this convention for importing stuff and > specifying base classes. So your example would be: > > class Applications: > class MyApp: > class Dirs: # virtual dirs like <location> in Apache > Services = '/home/tavis/MyApp/Services' > Products = '/home/tavis/MyApp/Products' > ApplicationClass = 'Foo:Bar' > RequestClass = 'Foo:Whiz' > SessionStoreClass = 'Foo:Bang' > The advantage is that you can import the config file without having > to actually import the class. Perhaps you're just running a config > file pretty-printing utility, and you don't want it to have to > actually do the import. What's the disadvantage in doing the imports? Performance isn't an issue here. If you want to pretty-print the config module, why not just "print open(configFile).read()" as it already has a pretty syntax? Tavis |
From: Geoffrey T. <gta...@na...> - 2001-12-10 21:40:52
|
At 02:39 PM 12/10/01 -0800, Tavis Rudd wrote: >On Monday 10 December 2001 13:11, Geoffrey Talvola wrote: > > At 01:59 PM 12/10/01 -0800, Tavis Rudd wrote: > > >Geoff, > > >going back to your class-based config syntax... > > > > > >The reason we'd need to subclass SettingsContainer is that it is > > >possible to have settings that are in fact classes and don't begin > > >with an underscore: > > > > > >## > > >from SettingsManager import SettingsContainer as SC > > >class Applications(SC): > > > class MyApp(SC): > > > class Dirs: # virtual dirs like <location> in Apache > > > Services = '/home/tavis/MyApp/Services' > > > Products = '/home/tavis/MyApp/Products' > > > from Foo import Bar as ApplicationClass > > > from Foo import Whiz as RequestClass > > > from Foo import Bang as SessionStoreClass > > >## > > > It seems very odd to me to have a value in a config file be an > > actual class object. I was expecting settings to be things like > > ints, strings, lists, dictionaries, tuples, etc. but all basically > > constants that didn't depend on code. > >That is part of a fundamental shift I'm proposing. If you use Python >for configs, why not fully exploit its capabilities? If the settings >are all constants strings then you are only using Python for its >pretty syntax. I'm interested in both the syntax and the dynamic >features of Python. Specifically, I want to be able to load either >constants, classes, or live pre-initialized objects into WebKit. > >Consider this example: > >## >from WebKit.Application import Application >class MyAppClass(Application): > # define some custom stuff that allows collaboration > # between two otherwise separate applications, such > # as doing some complex request chaining > >_myApp = MyAppClass('MyApp') >_partnerApp = MyAppClass('PartnerApp') >_myApp.setPartner(_partnerApp) > > >AppServer: > Applications: > MyApp = _myApp > PartnerApp = _partnerApp >## > >I don't think this sort of magic will be common, but it should be >possible. Why not just put the "magic" part into a separate source file? I don't see how putting this kind of stuff directly into the config file gains any real power. > > I would propose that to specify a class as a config setting, you > > would specify a string like "Package.Module:Class" where you can > > leave off the ":Class" part if the class name is the same as the > > module name. PSP uses this convention for importing stuff and > > specifying base classes. So your example would be: > > > > class Applications: > > class MyApp: > > class Dirs: # virtual dirs like <location> in Apache > > Services = '/home/tavis/MyApp/Services' > > Products = '/home/tavis/MyApp/Products' > > ApplicationClass = 'Foo:Bar' > > RequestClass = 'Foo:Whiz' > > SessionStoreClass = 'Foo:Bang' > > > > The advantage is that you can import the config file without having > > to actually import the class. Perhaps you're just running a config > > file pretty-printing utility, and you don't want it to have to > > actually do the import. > >What's the disadvantage in doing the imports? Performance isn't an >issue here. If you want to pretty-print the config module, why not >just >"print open(configFile).read()" as it already has a pretty syntax? In your own example above, importing the config file actually _creates_ two instance of application classes. This could have side effects that you don't expect to get just by loading a config file. It might cause lines to be written to logfiles. It might raise exceptions, preventing you from reading the rest of the config file. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Tavis R. <ta...@ca...> - 2001-12-10 21:49:23
|
On Monday 10 December 2001 13:42, Geoffrey Talvola wrote: > Why not just put the "magic" part into a separate source file? I > don't see how putting this kind of stuff directly into the config > file gains any real power. The end result would be the same either way, but I prefer doing it directly rather than implying that it should be done. > In your own example above, importing the config file actually > _creates_ two instance of application classes. This could have > side effects that you don't expect to get just by loading a config > file. It might cause lines to be written to logfiles. It might > raise exceptions, preventing you from reading the rest of the > config file. I see your point there, but if there's something wrong the exceptions will be raised anyway. If a user puts invalid syntax into file you won't be able to load it. If they put buggy code that raises exceptions then the effect is the same. Python will give them a good traceback and they can proceed from there. |
From: Tavis R. <ta...@ca...> - 2001-12-10 21:52:53
|
On Monday 10 December 2001 13:42, Geoffrey Talvola wrote: > In your own example above, importing the config file actually > _creates_ two instance of application classes. This could have > side effects that you don't expect to get just by loading a config > file. It might cause lines to be written to logfiles. It might > raise exceptions, preventing you from reading the rest of the > config file. This would aviod that: from WebKit.Application import Application class MyAppClass(Application): # define some custom stuff that allows collaboration # between two otherwise separate applications, such # as doing some complex request chaining AppServer: Applications: def __init__(self): # load those applications self.MyApp = MyAppClass('MyApp') self.PartnerApp = MyAppClass('PartnerApp') self.MyApp.setPartner(self.PartnerApp) |
From: Tavis R. <ta...@ca...> - 2001-12-10 22:20:06
|
Here's a shitty alternative that highlights the best points of your class-based suggestion: ## def S(**kw): return kw AppServer = S( Applictions = S( MyApp = S( Dirs = S(Products = '/home/tavis/Webware/Products' Services = '/home/tavis/Webware/Services' ) ) ) ) ## The syntax is only marginally better than plain dictionaries and you can't do cool things like: ## class _SharedSettings: foo = 1234 bar = 'aoeu' class AppServer: class Applications: Class MyApp(_SharedSettings): ... Class OtherApp(_SharedSettings): ... ## OR ## import os class AppServer: class Applications: Class MyApp: if os.name == 'NT': ... settings for NT else: ... settings for Posix systems ## and so on |