seaside-dev November 2009

seaside-dev@lists.squeakfoundation.org

11 participants
25 discussions

Re: [Seaside-dev] Detecting installed Seaside versions?
by Dale Henrichs 26 Nov '09

26 Nov '09

Colin, The down-side to having a constant in the image that records the "last version loaded" is that users are free to load packages independently, without ensuring that the "last version loaded" is updated appropriately. It is certainly a good enough solution. The point of Metacello is to create a specification for a particular version, so that no matter how that particular version got loaded the current image can be compared to the spec and the "current version" can be calculated. It's one of the fundamental problems with "Package management" - when the package data base does not match the installed system. Metacello is not immune to the problem, but since it dynamically calculates the version based on a spec and the existing image, it has a chance of getting a good answer. Ad hoc solutions start breaking down when a particular user is interested in reasoning about cross project dependencies, based on versions ... a problem that every current Smalltalk programmer has:) I'm not going to say that Metacello is the last word in package management for Smalltalk, but it _is_ an attempt to address some of the larger problems that the consumers of multiple software projects have to deal with... Dale ----- "Colin Putney" <cputney(a)wiresong.ca> wrote: | On 24-Nov-09, at 6:27 PM, Andreas Raab wrote: | | > I'm trying to answer the big picture question of "Does this image | > have Seaside installed, and if so, which version". | | I've run into this problem too, not with Seaside, but with my own | projects - OmniBrowser, Monticello and now Filesystem. I'm trying out | | a new strategy with Filesystem - the class FSReleaseInfo has a class | | variable called Current. The SAR install script sets it after the | install. So far FSReleaseInfo just has a version number, but it can | grow to include more metadata if necessary. The plan is to have the | install script for future versions check for the presence of | FSReleaseInfo and if it's there, use "FSReleaseInfo current version" | | to figure out what upgrade script to run. Andreas, I realize this | doesn't do you any good for the moment, but perhaps something similar | | could work for future releases of Seaside 3. | | For now I'd bet there *is* check-for-WAFrumbazzle-style algorithm out | | there, but somebody will have to do the analysis to figure out what it | | is. It might not be *that* complicated... I bet | "SeasidePlatformSupport versionString" is a good place to start. For | | the alpha versions of 2.9 and 3.0, there's been a lot of package | churn, so it shouldn't be hard to figure out what version is present | | based on that. Before SeasidePlatformSupport existed... well, how far | | back to you want to go? | | Colin | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

3 3

Re: [Seaside-dev] Detecting installed Seaside versions?
by Dale Henrichs 26 Nov '09

26 Nov '09

Colin, Very interesting work and if Metacello becomes extinct I would be a happier man ... When I read your mail, I was struck by the thought that perhaps your idea of the end user and my idea of the end user are different. And maybe I haven't been clear about who the Metacello end user is... The Metacello end user is another _developer_ who is trying to put together a system made up of a number of projects some of whom have dependencies upon one another and some of whom do not. The Metacello configurations provide version and dependency information to the developer to use for development purposes. It _is_ a glorified load script, but it is structured such that it does not need to be a _monolithic_ load script. It also happens to be a multi-platform load script. It also happens to be versioned, which is how this topic got started. The poster child developer for Metacello is someone who is building a collection of Seaside3.0 components that he expects other people to use in their own development projects. The poster child must ensure that when someone decides to use his component that they are able to get the right stuff loaded from the other projects that his component may depend upon (does it use AJAX, does it need email, does it do XML processing, does it need smacc...what parts of the Seaside3.0 package archipeligo does it really need)...The end user of the poster childs project needs to be able to independently integrate bugfixes from the packages that the poster childs component depends upon, so the end user needs dependency information as well...A single metacello configuration published by the poster child can provide all of the above information so the end user is not burdened by 'figuring out' what he needs to make it work nor does the end user have to wonder which version of Seaside3.0 9et.al) the component was originally written against, since that information is encoded in the configuration as well ... <deep breath>....:) My understanding (which is probably flawed) of SAR files is that they are monolithic entities ... there is no internal dependency information other than things are loaded in a fixed order.. there are no conditional loading options... there is no SAR to SAR external dependency information ...there is no way to load a partial graph from a SAR...These are the issues that Metacello is attempting to resolve. With that said SAR files sound like wonderful things for delivering a finished product to someone and from that perspective Metacello is uninteresting. In the end I think that Metacello and SAR are tools aimed at different problems. Dale ----- "Colin Putney" <cputney(a)wiresong.ca> wrote: | On 25-Nov-09, at 9:45 AM, Dale Henrichs wrote: | | > Colin, | > | > The down-side to having a constant in the image that records the | > "last version loaded" is that users are free to load packages | > independently, without ensuring that the "last version loaded" is | > updated appropriately. | > | > It is certainly a good enough solution. | > | > The point of Metacello is to create a specification for a particular | | > version, so that no matter how that particular version got loaded | > the current image can be compared to the spec and the "current | > version" can be calculated. | > | > It's one of the fundamental problems with "Package management" - | > when the package data base does not match the installed system. | > Metacello is not immune to the problem, but since it dynamically | > calculates the version based on a spec and the existing image, it | > has a chance of getting a good answer. | > | > Ad hoc solutions start breaking down when a particular user is | > interested in reasoning about cross project dependencies, based on | | > versions ... a problem that every current Smalltalk programmer | has:) | > | > I'm not going to say that Metacello is the last word in package | > management for Smalltalk, but it _is_ an attempt to address some of | | > the larger problems that the consumers of multiple software projects | | > have to deal with... | | I think one of the biggest problems Squeak (and Gemstone, to the | extent that it participates in the Squeak ecosystem) has today is that | | there aren't any good mechanisms for distributing code for deployment. | | Monticello makes a reasonably good versioning tool for development, | but it was not designed for *distributing* software. It does have the | | nifty property that a package version is contained in a single file, | | and so we've been using Monticello's internal repository format as a | | distribution format. Just download an mcz file and load it into your | | image! | | That wasn't great, but it worked OK in the early days of Monticello | when most projects were single, monolithic packages. These days, | though, we've got large, multi-platform projects being developed with | | Monticello, and configuration management at the level of packages gets | | really difficult. OmniBrowser has over a dozen, Monticello 2.0 has | over two dozen, and Seaside has about 5 dozen! So we've had a little | | cottage industry of scripts to pull down all those packages and get | them installed. | | This is bad for many reasons, but I think the worst effect is to | introduce coupling between the users' installation process and the | developers' development process. All these scripts rely on knowing how | | the source code of the project is organized, where it's stored, and | perhaps even the social dynamics of the development team. If I decide | | to start using Monticello 2 to develop OmniBrowser, or even move my | repository to another host, it's going to break all those installation | | scripts that people have put together. | | I'd like to find a better way to distribute Squeak applications, and | | for my own projects I'm trying to break that coupling between | installation and development. For example, I've started releasing OB, | | MC2 and Filesystem using SAR archives rather than mcz files. This | removes the need for users to have Monticello installed, and if my | FSReleaseInfo experiment pans out, will make it possible to upgrade to | | future SAR-based releases easily, again without using Monticello. | | Now, it's true, this scheme only works if you install and upgrade | using my SAR releases, but I don't think that's an unreasonable | requirement. If all you want to do is *use* my application, as opposed | | to hacking on it, you don't need to install things manually anyway. | Folks who want to participate in development, on the other hand, will | | need to know where the repositories are, what the packages are and | their relationships etc, but that's to be expected. | | The problem I have with Metacello is that it's really just a cleaner, | | more managable version of the install scripts I'm trying to get rid | of. On top of that, it introduces a new dependency for installation - | | now users have to have Metacello installed as well as Monticello. | Where I find Metacello valuable is as a development tool, for managing | | the metadata I need to reliably build development images and SAR | archives. Unfortunately Metacello wasn't designed for that role, and | | I'm not terribly comfortable twisting it to my purposes, because | that's what got us in this mess in the first place. :-) | | Colin | | | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

1 0

Re: [Seaside-dev] Detecting installed Seaside versions?
by Dale Henrichs 25 Nov '09

25 Nov '09

Adreas, _If_ Metacello were being used to load/manage Seaside, then it could be used to provide the answer to your question. I _have_ built a "general use" configuration for managing Seaside3.0, but I have not built one for Seaside 2.8. You are correct that one would need to build a "general use" configuration to take advantage of Metacello for Seasdie 2.8. There is no WAVersion so that answer is not an option. Metacello is intended to manage versions of projects which is why it is mentioned at all. Metacello was mentioned in the context of "if you are going to build something to solve Andreas' problem, you might consider Metacello as an option." The best you can do right now is use the Seaside2.8 package number to divine what version of Seaisde2.8 is installed (2.8.4 -> Seaside2.8a1-lr.591, 2.8.3 -> Seaside2.8a1-pmm.573, 2.8.2 -> Seaside2.8a1-lr.563, 2.8.1 -> Seaside2.8a1-lr.541). For Seaside 3.0 there are a number of packages involved so the "version signature" is not as simple ... Metacello would be a better option in that case... Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | Hi Dale - | | I'm getting confused here. What I'm practically trying to do is along | | the lines of giving a warning if a user asks to install Seaside 3.0 on | | top of an earlier version of Seaside, and just allow the request to | pass | if Seaside 3.0 is already installed. I expected to get some responses | | along the lines "use WAVersion seasideMajor and WAVersion | seasideMinor" | or somesuch or at worst something along the lines of "You can detect | Seaside x.y by looking for WAFooBar and WAFrumbazzle because WAFooBar | | first appeared in version x.y and WAFrumbazzle appeared in version | x.z". | | I'm not sure how to interpret your comment about not having *built* a | | Metacello configuration in this context. I must be misunderstanding | what | Metacello is. I can't imagine that in order to detect an installed | Seaside version one must first build a cross-platform Metacello | configuration. Are we really talking about the same thing here? Could | | you maybe explain from first principles what Metacello is and why it | would be the Right Thing to use for detecting an installed Seaside | version? | | Horribly confused, | - Andreas | | Dale Henrichs wrote: | > I haven't built a cross platform Metacello configuration for | Seaside2.8, but I have built one for GLASS. If you load the latest | version of the ConfigurationOfGsSeaside28 package from | http://seaside.gemstone.com/ss/seaside you can see what a | configuration would look like (a metacello config can be loaded since | the config has not dependencies). | > | > If this configuration had been built for more than GLASS, you'd | execute the following expression to determine what version of | Seaside2.8 is loaded: | > | > ConfigurationOfGsSeaside28 project currentVersion | > | > Executing that expression would cause Metacello itself to be loaded | (if it hadn't already been loaded). | > | > The idea behind Metacello is that you'd use it to also load version | 2.8.4 of Seaside2.8 into your image, by executing something like the | following: | > | > (ConfigurationOfGsSeaside28 project version: '2.8.4') load | > | > In the end the Metacello configuration is a map between a collection | of Monticello packages and a specific version number, that map can be | used to load a particular version of a project or to determine which | version is (probably) installed. Metacello doesn't store state... | > | > Does this help? | > | > Dale | > | > ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | > | > | I have zero experience with Metacello (I know hardly more about | it | > | then | > | it's name) but let's try an example: Assume I'm downloading one of | the | > | | > | older 2.8 images, what do I need to do to have Metacello tell me | "this | > | | > | image has Seaside 2.8 installed"? | > | | > | Cheers, | > | - Andreas | > | | > | Julian Fitzell wrote: | > | > Right... that could be a viable option... | > | > | > | > On Tue, Nov 24, 2009 at 11:39 AM, Dale Henrichs | > | > <dale.henrichs(a)gemstone.com> wrote: | > | >> If you use Metacello, it has the ability to calculate the | current | > | version of a project (a MetacelloVersionNumber) ... so | > | >> | > | >> ConfigurationOfSeaside30 project currentVersion | > | >> | > | >> would do the trick:) | > | >> | > | >> Dale | > | >> | > | >> ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | > | >> | > | >> | We don't really have a solution to that at the moment. | Obviously | > | the | > | >> | MC version for the Core package gives some indication but | > | clearly | > | >> | that's not really good enough. | > | >> | | > | >> | In Seaside 2.8, you can do "SeasidePlatformSupport | > | versionString", | > | >> | though it would probably be nice to have an array like {2. 8. | 1} | > | or | > | >> | something... maybe a WAVersion object would be better than | an | > | array | > | >> | since it could do comparisons and printing and so on. | "WAVersion | > | >> | current" could return an appropriate instance. Part of me | hates | > | >> | having | > | >> | to modify the code to specify the version number, but the | > | alternative | > | >> | is to have an install script do it, which is also kind of | lame. | > | >> | | > | >> | Ok, enough rambling; clearly I, at least, am open to | suggestions. | > | :) | > | >> | | > | >> | Julian | > | >> | | > | >> | On Tue, Nov 24, 2009 at 1:33 AM, Andreas Raab | > | <andreas.raab(a)gmx.de> | > | >> | wrote: | > | >> | > Hi - | > | >> | > | > | >> | > Curious: How does one detect an installed Seaside version? | > | I.e., | > | >> | assuming | > | >> | > that one would want to detect that an image has Seaside | loaded | > | >> | already, how | > | >> | > would one determine its version? | > | >> | > | > | >> | > Cheers, | > | >> | > - Andreas | > | >> | > _______________________________________________ | > | >> | > seaside-dev mailing list | > | >> | > seaside-dev(a)lists.squeakfoundation.org | > | >> | > | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | >> | > | > | >> | _______________________________________________ | > | >> | seaside-dev mailing list | > | >> | seaside-dev(a)lists.squeakfoundation.org | > | >> | | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | >> _______________________________________________ | > | >> seaside-dev mailing list | > | >> seaside-dev(a)lists.squeakfoundation.org | > | >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | >> | > | > _______________________________________________ | > | > seaside-dev mailing list | > | > seaside-dev(a)lists.squeakfoundation.org | > | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | > | >

4 5

Re: [Seaside-dev] Detecting installed Seaside versions?
by Dale Henrichs 25 Nov '09

25 Nov '09

I haven't built a cross platform Metacello configuration for Seaside2.8, but I have built one for GLASS. If you load the latest version of the ConfigurationOfGsSeaside28 package from http://seaside.gemstone.com/ss/seaside you can see what a configuration would look like (a metacello config can be loaded since the config has not dependencies). If this configuration had been built for more than GLASS, you'd execute the following expression to determine what version of Seaside2.8 is loaded: ConfigurationOfGsSeaside28 project currentVersion Executing that expression would cause Metacello itself to be loaded (if it hadn't already been loaded). The idea behind Metacello is that you'd use it to also load version 2.8.4 of Seaside2.8 into your image, by executing something like the following: (ConfigurationOfGsSeaside28 project version: '2.8.4') load In the end the Metacello configuration is a map between a collection of Monticello packages and a specific version number, that map can be used to load a particular version of a project or to determine which version is (probably) installed. Metacello doesn't store state... Does this help? Dale ----- "Andreas Raab" <andreas.raab(a)gmx.de> wrote: | I have zero experience with Metacello (I know hardly more about it | then | it's name) but let's try an example: Assume I'm downloading one of the | | older 2.8 images, what do I need to do to have Metacello tell me "this | | image has Seaside 2.8 installed"? | | Cheers, | - Andreas | | Julian Fitzell wrote: | > Right... that could be a viable option... | > | > On Tue, Nov 24, 2009 at 11:39 AM, Dale Henrichs | > <dale.henrichs(a)gemstone.com> wrote: | >> If you use Metacello, it has the ability to calculate the current | version of a project (a MetacelloVersionNumber) ... so | >> | >> ConfigurationOfSeaside30 project currentVersion | >> | >> would do the trick:) | >> | >> Dale | >> | >> ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | >> | >> | We don't really have a solution to that at the moment. Obviously | the | >> | MC version for the Core package gives some indication but | clearly | >> | that's not really good enough. | >> | | >> | In Seaside 2.8, you can do "SeasidePlatformSupport | versionString", | >> | though it would probably be nice to have an array like {2. 8. 1} | or | >> | something... maybe a WAVersion object would be better than an | array | >> | since it could do comparisons and printing and so on. "WAVersion | >> | current" could return an appropriate instance. Part of me hates | >> | having | >> | to modify the code to specify the version number, but the | alternative | >> | is to have an install script do it, which is also kind of lame. | >> | | >> | Ok, enough rambling; clearly I, at least, am open to suggestions. | :) | >> | | >> | Julian | >> | | >> | On Tue, Nov 24, 2009 at 1:33 AM, Andreas Raab | <andreas.raab(a)gmx.de> | >> | wrote: | >> | > Hi - | >> | > | >> | > Curious: How does one detect an installed Seaside version? | I.e., | >> | assuming | >> | > that one would want to detect that an image has Seaside loaded | >> | already, how | >> | > would one determine its version? | >> | > | >> | > Cheers, | >> | > - Andreas | >> | > _______________________________________________ | >> | > seaside-dev mailing list | >> | > seaside-dev(a)lists.squeakfoundation.org | >> | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | >> | > | >> | _______________________________________________ | >> | seaside-dev mailing list | >> | seaside-dev(a)lists.squeakfoundation.org | >> | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | >> _______________________________________________ | >> seaside-dev mailing list | >> seaside-dev(a)lists.squeakfoundation.org | >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | >> | > _______________________________________________ | > seaside-dev mailing list | > seaside-dev(a)lists.squeakfoundation.org | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | >

2 1

Re: [Seaside-dev] Detecting installed Seaside versions?
by Dale Henrichs 24 Nov '09

24 Nov '09

If you use Metacello, it has the ability to calculate the current version of a project (a MetacelloVersionNumber) ... so ConfigurationOfSeaside30 project currentVersion would do the trick:) Dale ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | We don't really have a solution to that at the moment. Obviously the | MC version for the Core package gives some indication but clearly | that's not really good enough. | | In Seaside 2.8, you can do "SeasidePlatformSupport versionString", | though it would probably be nice to have an array like {2. 8. 1} or | something... maybe a WAVersion object would be better than an array | since it could do comparisons and printing and so on. "WAVersion | current" could return an appropriate instance. Part of me hates | having | to modify the code to specify the version number, but the alternative | is to have an install script do it, which is also kind of lame. | | Ok, enough rambling; clearly I, at least, am open to suggestions. :) | | Julian | | On Tue, Nov 24, 2009 at 1:33 AM, Andreas Raab <andreas.raab(a)gmx.de> | wrote: | > Hi - | > | > Curious: How does one detect an installed Seaside version? I.e., | assuming | > that one would want to detect that an image has Seaside loaded | already, how | > would one determine its version? | > | > Cheers, | > - Andreas | > _______________________________________________ | > seaside-dev mailing list | > seaside-dev(a)lists.squeakfoundation.org | > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev | > | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

3 2

Detecting installed Seaside versions?
by Andreas Raab 24 Nov '09

24 Nov '09

Hi - Curious: How does one detect an installed Seaside version? I.e., assuming that one would want to detect that an image has Seaside loaded already, how would one determine its version? Cheers, - Andreas

2 1

Re: [Seaside-dev] WAMutualExclusionFilter
by Julian Fitzell 24 Nov '09

24 Nov '09

Why didn't this email go to the Seaside dev list as well? sigh... On Mon, Nov 23, 2009 at 5:19 PM, Julian Fitzell <jfitzell(a)gmail.com> wrote: > What I'm suggesting would put the transaction handler a few contexts > later. "self requestHandler" would return a particular request handler > that could be set/configured by the server adaptor itself. Your server > adaptor could configure that handler by adding several filters to do > logging/transactions/retry in whatever order it liked. > > Once its filters had finished processing, the special request handler > would dispatch to the root handler specified by the user (usually a > Dispatcher). > > I'd like to avoid another layer of handlers if possible... would it be > enough to catch WAResponseNotification, do something, then send #next? > I keep meaning to provide an ensure-like method that does that > automatically so that filters can specify behaviour that happens > either when a block finishes *or* when a response is sent back. > > Julian > > On Mon, Nov 23, 2009 at 2:21 PM, Dale Henrichs > <dale.henrichs(a)gemstone.com> wrote: >> Julian, >> >> Yes that sounds like it is in the right area ... it would be a bonus to have the transaction handling inserted underneath the error handling for the session (and a bonus to insert special exception handlers above the error handlers for dealing with retry). For logging, at times it is useful to be able to get your hands on the WARequest/REsponse .. I like to drop them into the object log. >> >> Some of the tracing that I do must be done in conjunction with the transaction boundaries, so being able to swap in and out different transaction handlers is necessary too. >> >> Looking at the stack, the transaction handler/logger probably needs to be wrapped around WAServerAdaptor>>handleRequest: ... since we're interested in the request/response boundary, but I assume that can be achieved by making the WAResponseNotification handler a separate handler layer in and of itself.. >> >> Dale >> >> ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: >> >> | On Sat, Nov 21, 2009 at 9:37 AM, Dale Henrichs >> | <dale.henrichs(a)gemstone.com> wrote: >> | > >> | > ----- "Philippe Marschall" <philippe.marschall(a)gmail.com> wrote: >> | > >> | > | <rant> >> | > | We have that over and over again. Error handlers, key generators, >> | > | codecs, semaphores, .... Every time we do a different hack, >> | looking >> | > | at >> | > | subclasses, looking at some class var somewhere, liking against a >> | > | platform provided class, looking the class up in WAPlatform, .... >> | I'm >> | > | fucking sick of it, I want dependency injection! >> | > | </rant> >> | > >> | > Is there a reason for not using dependency injection? We do have >> | quite a few moving/configurable parts and it sure would be convenient >> | to have a single spot to manage the choices .... >> | > >> | > Hmmm, perhaps the injector, should be configured prior to the >> | loading of the code ... the developer decides how they want there >> | Seaside instance configured (making error >> | handling/codec/decorator/adaptor choices), then a system that matches >> | those specs is loaded ... over time as the composition of the system >> | (and even the implementation changes), the same choices could be >> | preserved ... >> | > >> | > Okay, I'll add a method to GRPlatform:) >> | > >> | > Seriously, though. For the short term I will create a >> | gemstone-specific branch on the session package with the hope that a >> | better approach becomes available. >> | > >> | > I _am_ also looking at a putting decorator-style handlers in the >> | Adaptor stack for transactions, logging and maybe even >> | conversion...maybe I'll play with dependency injection there? >> | >> | We discussed creating a special RequestHandler to represent the >> | server >> | adaptor as the first handler in the handler stack. I think this would >> | simplify a few things, for example allowing that adaptor to alter the >> | generated URLs based on information obtained from the server adaptor >> | itself. Obviously it could provide default error handling (or be >> | wrapped in a request filter), though I wondered if that would be >> | quite >> | high enough? >> | >> | I started implementing this at one point but then was not sure there >> | were enough immediate benefits to avoid it looking like >> | over-engineering. Would something like this address help with what >> | you >> | want to do? >> | >> | Julian >> >

1 0

WAMutex
by Dale Henrichs 24 Nov '09

24 Nov '09

I'd like to swap out the grease method for #semaphoreClass, with a grease method to answer with the #mutex class (which would involve moving WAMutex to Grease) .. the only other place that the semaphoreClass is used is in a test and since that's not involved in persistence it could be a real semaphore in GemStone too... Of course, we could leave the #semaphoreClass method just in case it needs to be used in the future ... Since WAMutexes(WAMutexi?) are persisted, I need transient protection for both the Semaphore and process references ... the process could have a direct Semaphore reference in the stack .... WAMutex is used in WAMutualExclusionFilter and WACache ... I _could_ subclass WACache, but then I'd want a way to inject the GemStone cache as the default since WACache would not be usable/recommended in GemStone... Again, for the short term, I can create a GemStone-specific package witht a direct override until we come up with a satisfactory resolution for this and the other issues I'm sure to bump into. If a solution is a no-brainer, then we should do it relatively soon, but if we're choosing between hacks, then it is worth waiting until I've uncovered more of the persistence issues... Dale

2 1

Re: [Seaside-dev] WAMutualExclusionFilter
by Dale Henrichs 23 Nov '09

23 Nov '09

Julian, Yes that sounds like it is in the right area ... it would be a bonus to have the transaction handling inserted underneath the error handling for the session (and a bonus to insert special exception handlers above the error handlers for dealing with retry). For logging, at times it is useful to be able to get your hands on the WARequest/REsponse .. I like to drop them into the object log. Some of the tracing that I do must be done in conjunction with the transaction boundaries, so being able to swap in and out different transaction handlers is necessary too. Looking at the stack, the transaction handler/logger probably needs to be wrapped around WAServerAdaptor>>handleRequest: ... since we're interested in the request/response boundary, but I assume that can be achieved by making the WAResponseNotification handler a separate handler layer in and of itself.. Dale ----- "Julian Fitzell" <jfitzell(a)gmail.com> wrote: | On Sat, Nov 21, 2009 at 9:37 AM, Dale Henrichs | <dale.henrichs(a)gemstone.com> wrote: | > | > ----- "Philippe Marschall" <philippe.marschall(a)gmail.com> wrote: | > | > | <rant> | > | We have that over and over again. Error handlers, key generators, | > | codecs, semaphores, .... Every time we do a different hack, | looking | > | at | > | subclasses, looking at some class var somewhere, liking against a | > | platform provided class, looking the class up in WAPlatform, .... | I'm | > | fucking sick of it, I want dependency injection! | > | </rant> | > | > Is there a reason for not using dependency injection? We do have | quite a few moving/configurable parts and it sure would be convenient | to have a single spot to manage the choices .... | > | > Hmmm, perhaps the injector, should be configured prior to the | loading of the code ... the developer decides how they want there | Seaside instance configured (making error | handling/codec/decorator/adaptor choices), then a system that matches | those specs is loaded ... over time as the composition of the system | (and even the implementation changes), the same choices could be | preserved ... | > | > Okay, I'll add a method to GRPlatform:) | > | > Seriously, though. For the short term I will create a | gemstone-specific branch on the session package with the hope that a | better approach becomes available. | > | > I _am_ also looking at a putting decorator-style handlers in the | Adaptor stack for transactions, logging and maybe even | conversion...maybe I'll play with dependency injection there? | | We discussed creating a special RequestHandler to represent the | server | adaptor as the first handler in the handler stack. I think this would | simplify a few things, for example allowing that adaptor to alter the | generated URLs based on information obtained from the server adaptor | itself. Obviously it could provide default error handling (or be | wrapped in a request filter), though I wondered if that would be | quite | high enough? | | I started implementing this at one point but then was not sure there | were enough immediate benefits to avoid it looking like | over-engineering. Would something like this address help with what | you | want to do? | | Julian

1 0

Re: [Seaside-dev] WAMutualExclusionFilter
by Dale Henrichs 23 Nov '09

23 Nov '09

----- "Philippe Marschall" <philippe.marschall(a)gmail.com> wrote: | <rant> | We have that over and over again. Error handlers, key generators, | codecs, semaphores, .... Every time we do a different hack, looking | at | subclasses, looking at some class var somewhere, liking against a | platform provided class, looking the class up in WAPlatform, .... I'm | fucking sick of it, I want dependency injection! | </rant> Is there a reason for not using dependency injection? We do have quite a few moving/configurable parts and it sure would be convenient to have a single spot to manage the choices .... Hmmm, perhaps the injector, should be configured prior to the loading of the code ... the developer decides how they want there Seaside instance configured (making error handling/codec/decorator/adaptor choices), then a system that matches those specs is loaded ... over time as the composition of the system (and even the implementation changes), the same choices could be preserved ... Okay, I'll add a method to GRPlatform:) Seriously, though. For the short term I will create a gemstone-specific branch on the session package with the hope that a better approach becomes available. I _am_ also looking at a putting decorator-style handlers in the Adaptor stack for transactions, logging and maybe even conversion...maybe I'll play with dependency injection there? Dale

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev November 2009