From: Stuart D. <st...@as...> - 2003-01-29 02:30:02
|
I am trying to stick to the plan outlined a couple weeks ago on the 0.8 release. The goal being to get the mostly stable current development version in CVS released as 0.8 in the near future. There are a couple of recent issues that I wanted to touch on. ** Regarding the Page.writeDocType() method ** The 0.7 behavior was to return a 4.01 transitional doctype. The current behavior is to return nothing. However this apparently breaks some 0.7 installations, and debugging such a problem can be a pain. If left as is, it needs a good comment in the release notes. Chuck, I think you were the one that changed the default because of instability in Mozilla. But it is not clear to me anyway that the Mozilla problem remains. Any thoughts on this? My interpretation of the consensus on the mailing list is that we should restore the 0.7 behavior, and add a note to the Release Notes highlighting the potential problem of an incorrect DocType string for the HTML you are generating. Also noting that the behavior has reverted to 0.7 as opposed to following the last several months of CVS behavior. If anyone wants to suggest some other DocType strings and information to be added to the Release Notes, Users Guide, or to the writeDocType doc string please do so. I don't have a high degree of confidence in this approach not being a pain, because the CVS trunk has behaved differently for so long. But it seemed like the way to go from the e-mail threads. ** Regarding the SessionMemoryStore and saving to disk. ** It appears unlikely from the e-mail thread that many people are using the SessionMemoryStore relying on the save to disk behavior. The direction I think we are leaning is to remove that capability of the SessionMemoryStore, making it memory-only and not persistent. While the risks of changing this for 0.8 may be low, I am not sure that the benefit in changing the paradigm from established behavior is worth it at this point. I currently lean towards leaving this until after 0.8. ** Disclaimer ** I am trying to err on the side of caution, and expeditious release of 0.8. Beyond that, we can come out with a 0.8.1 if necessary if we decide we want more changes in the way things work. -Stuart- |
From: Ian B. <ia...@co...> - 2003-01-29 02:38:54
|
On Tue, 2003-01-28 at 20:29, Stuart Donaldson wrote: > ** Regarding the SessionMemoryStore and saving to disk. ** > > It appears unlikely from the e-mail thread that many people are using > the SessionMemoryStore relying on the save to disk behavior. The > direction I think we are leaning is to remove that capability of the > SessionMemoryStore, making it memory-only and not persistent. I don't think it's a good idea to change this, at least not at this point. It seems better to create a new session store (NonPersistentMemory or something), and perhaps to deprecate Memory (i.e., print a warning message). Then maybe restoring a new Memory behavior (i.e, reusing that name), or just adding another kind of session store. I think it would be fine to include such a new session store (particularly if someone offers tested code for it), since it shouldn't effect the rest of Webware very much. -- Ian Bicking Colorstudy Web Development ia...@co... http://www.colorstudy.com PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7 4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241 |
From: Stuart D. <st...@as...> - 2003-01-29 05:36:01
|
Ian Bicking wrote: >On Tue, 2003-01-28 at 20:29, Stuart Donaldson wrote: > > >>** Regarding the SessionMemoryStore and saving to disk. ** >> >>It appears unlikely from the e-mail thread that many people are using >>the SessionMemoryStore relying on the save to disk behavior. The >>direction I think we are leaning is to remove that capability of the >>SessionMemoryStore, making it memory-only and not persistent. >> >> > >I don't think it's a good idea to change this, at least not at this >point. It seems better to create a new session store >(NonPersistentMemory or something), and perhaps to deprecate Memory >(i.e., print a warning message). Then maybe restoring a new Memory >behavior (i.e, reusing that name), or just adding another kind of >session store. > >I think it would be fine to include such a new session store >(particularly if someone offers tested code for it), since it shouldn't >effect the rest of Webware very much. > > > Agreed that this is not the time to change the behavior of SessionMemoryStore. I think what would be useful, is a mechanism to have non-persistent data associated with a session. But to not necessarily require that all session data be non-persistent. This can be done now via a mechanism similar to what I described earlier, using a non-persistent dictionary keyed on the session, and containing the non-persistent data. However it would be nice to have a "standard" API for this at some point. But I digress, at this point I think even for that, it would be best to address it after the 0.8 release. Putting something in the release adds pressure for some level of support in the future. And if we are adding new functionality to the release, I think it better to have it thought out and tried for a while in development, to give others more opportunity to comment on it and refine it. Just my 2-bits. If someone wants to propose a NonPersistentMemory store as an experimental feature, I could see including it. But I want to release 0.8b2 on Wednesday, and I would like ot to be a final beta prior to release. -Stuart- |
From: Aaron H. <aaron@MetroNY.com> - 2003-01-29 15:18:45
|
> If someone wants to propose a NonPersistentMemory store as an > experimental feature, I could see including it. But I want to release > 0.8b2 on Wednesday, and I would like ot to be a final beta prior to release. What is meant by NonPersistentMemory? Are we talking about when the app server shutsdown and restarts? I had a problem where when I restarted the app server I did not want the old sessions, so I added like to clean the seesion folder. I think that the next session code / API upgrade should pay more attention to the load balacing and app server affinity. - Maybe a session prefix code could tell the adapter what server the session started on - so the adapter could keep that user on that app server for the duration of thier visit. I used another cookie for this, but it was a hack and I abandoned it in favor of a bigger server. -Aaron |
From: Stuart D. <st...@as...> - 2003-01-29 15:41:17
|
Aaron Held wrote: >> If someone wants to propose a NonPersistentMemory store as an >> experimental feature, I could see including it. But I want to >> release 0.8b2 on Wednesday, and I would like ot to be a final beta >> prior to release. > > > What is meant by NonPersistentMemory? > Are we talking about when the app server shutsdown and restarts? > I had a problem where when I restarted the app server I did not want > the old sessions, so I added like to clean the seesion folder. Yes, currently with SessionDynamicStore, and SessionMemoryStore, the sessions are persistent acrsoss AppServer restarts. This causes problems for anyone keeping data in a session object which can't be pickled. You could always force it clear by calling application().sessions().clear() However this can't be done in a shutDownHandler because those get called after the sessions have been saved. I'm sure some solution to the issue will be forthcoming after the 0.8 release. > I think that the next session code / API upgrade should pay more > attention to the load balacing and app server affinity. - Maybe a > session prefix code could tell the adapter what server the session > started on - so the adapter could keep that user on that app server > for the duration of thier visit. I used another cookie for this, but > it was a hack and I abandoned it in favor of a bigger server. > > -Aaron > I haven't looked into any load balancing issues myself, just curious, how are you doing this, and with which adapter? Are you running multiple AppServers on a single system? Or directing them off to different systems in the adapter? Or using Apache for this? -Stuart- |
From: Aaron H. <aaron@MetroNY.com> - 2003-01-29 17:25:55
|
> I haven't looked into any load balancing issues myself, just curious, > how are you doing this, and with which adapter? Are you running > multiple AppServers on a single system? Or directing them off to > different systems in the adapter? Or using Apache for this? > > -Stuart- Originally I used the WebKit.cgi and edited the file to read the cookie and then pick the appserver based on the seesion ID Then I changed it to something much simpler. When the user logged in they were redirected either to http://www1 or http://www2 and then all of the links were relative. In apache I simply had two instanced of the webware adapter and used a rewrite rule to pick the correct one based on the url. A hack, but it worked. If for some reason the user typed the URL into thier browser again (or used a bookmark), then they MAY be forced to login again. Not a great solution, but an easy one to setup. -Aaron |