[Pharo-project] Zinc feedback
Hi Sven with igor we went over the start up list and we saw that ZnServer resgiter all subclasses of ZnServer. We think that it would be better to have a list of servers to be registered and that users can decide. What do you think? Stef
Stef, On 20 May 2011, at 08:57, Stéphane Ducasse wrote:
Hi Sven
with igor we went over the start up list and we saw that ZnServer resgiter all subclasses of ZnServer. We think that it would be better to have a list of servers to be registered and that users can decide. What do you think?
Stef
It is the traditional/classic idea that a server object in Smalltalk should survive image save/load. This is very convenient for beginners and during development. For production systems, explicit control is better. Now that I look at the code again, I must agree that it is a bit weird: only those server registered/started as the default in their class fall under this scheme, not other instances. So yes, an explicit managed list of ZnServer subclasses that need startup/shutdown would be nicer. If that is what you mean. Sven
On 20 May 2011 10:08, Sven Van Caekenberghe <sven@beta9.be> wrote:
Stef,
On 20 May 2011, at 08:57, Stéphane Ducasse wrote:
Hi Sven
with igor we went over the start up list and we saw that ZnServer resgiter all subclasses of ZnServer. We think that it would be better to have a list of servers to be registered and that users can decide. What do you think?
Stef
It is the traditional/classic idea that a server object in Smalltalk should survive image save/load. This is very convenient for beginners and during development. For production systems, explicit control is better.
Now that I look at the code again, I must agree that it is a bit weird: only those server registered/started as the default in their class fall under this scheme, not other instances.
So yes, an explicit managed list of ZnServer subclasses that need startup/shutdown would be nicer. If that is what you mean.
Yes. This is what i meant :) Because Default means only single server. While actually there could be as many servers as you want. So, during image startup, there should be a registration mechanism, which registers servers and starting them up. Instead of 'Default' single instance.
Sven
-- Best regards, Igor Stasenko AKA sig.
Igor, On 20 May 2011, at 10:32, Igor Stasenko wrote:
So, during image startup, there should be a registration mechanism, which registers servers and starting them up. Instead of 'Default' single instance.
Currently, all ZnServers understand #start and #stop (which could be renamed or aliased to #startUp and #shutDown). And there is a system wide startup list whose objects receive #startUp and #shutDown when needed. (I believe there is also this boolean saying if it is just an image save or a real quit, no ?) So there are 2 possibilities: 1. Zn manages its own list and registers its manager for that just once 2. each Zn server instance registers itself directly (less work for me, more reuse) Sven
I had the impression that 1 is better more self contained.
So, during image startup, there should be a registration mechanism, which registers servers and starting them up. Instead of 'Default' single instance.
Currently, all ZnServers understand #start and #stop (which could be renamed or aliased to #startUp and #shutDown).
And there is a system wide startup list whose objects receive #startUp and #shutDown when needed. (I believe there is also this boolean saying if it is just an image save or a real quit, no ?)
So there are 2 possibilities:
1. Zn manages its own list and registers its manager for that just once
2. each Zn server instance registers itself directly (less work for me, more reuse)
Sven
On 20 May 2011, at 10:46, Sven Van Caekenberghe wrote:
1. Zn manages its own list and registers its manager for that just once
On May 20, 2011, at 10:08 AM, Sven Van Caekenberghe wrote:
Stef,
On 20 May 2011, at 08:57, Stéphane Ducasse wrote:
Hi Sven
with igor we went over the start up list and we saw that ZnServer resgiter all subclasses of ZnServer. We think that it would be better to have a list of servers to be registered and that users can decide. What do you think?
Stef
It is the traditional/classic idea that a server object in Smalltalk should survive image save/load. This is very convenient for beginners and during development. For production systems, explicit control is better.
Now that I look at the code again, I must agree that it is a bit weird: only those server registered/started as the default in their class fall under this scheme, not other instances.
So yes, an explicit managed list of ZnServer subclasses that need startup/shutdown would be nicer. If that is what you mean.
Yes :)
Sven
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe