Environment(s) serving web pages

http://osrcon.ca/enviros.png
http://osrcon.ca/chrome.png

I wanted to have the same class serve web content from three
Environments. I loaded KomHttpServer and HttpView2 and did so.

(I would have used GreenNeon, but WebClient restricts one port per
image. It has a singleton, etc. KomHttpServer lets you have as many
ports per image as you'd like.)

Why would you do this? Perhaps to save resources like RAM. Instead of
having a Unix process per user you have a Smalltalk process per user. Or
users could share a common class side persistence. Or to have one VNC
connection for several applications. Most likely, because you cannot
resist trying it out.

Chris

On 27.06.2012 22:58, Colin Putney wrote:
> Nice! This might also be useful for live updates to a web application.
> Instead of loading code updates abruptly, as we do now, we could load
> the new version of the app into a separate environment. New sessions
> would be directed to the new environment, and existing sessions would
> continue to use the old environment. Once all the sessions expire, the
> old environment gets removed.
>
> Colin

that reminds me,
Erlang has a similar mechanism for handling
code updates, by specifying "switch points"
(I can't remember the correct name) where
a process moves from one version of the code
to the next at controlled execution points
(in the above example, when a new session
is created).

In Erlang, the scheme is more rigid, i.e.
when all processes use the new code,
the old code gets unloaded. IIRC you can only have
2 versions (old and new) and you have to wait
for all processes to switch over before
being able to introduce yet another, newer version
of the code.

I find it interesting that the new version of
the code is able to "see" the old version
if I understand environments correctly
(the old version could export an alias that
the new version can refer to).

Nice possibilities :)
thanks,
Wolfgang

Chris Cunnington-3 wrote

(I would have used GreenNeon, but WebClient restricts one port per
image. It has a singleton, etc. KomHttpServer lets you have as many
ports per image as you'd like.)

Not sure what you mean. Do you mean you'd like to have one WebServer instance listening on multiple ports? What would be the use case for this? This would be simple to add, I just hadn't considered it.

If you mean creating multiple WebServer instances, this is of course possible, simply by doing:
  wc8080 := WebServer new listenOn: 8080.
  wc8888 := WebServer new listenOn: 8888.
etc.

Cheers,
  - Andreas

I didn't mean to say WebClient was limited. The truth of the situation is that I built things around the examples you put into WebServer examples, which depend on #default and #reset. You do say in #default that it's mainly their to facilitate the examples. But as I haven't looked at my own code for several months, it was easier to jump to Kom.

"Not sure what you mean. Do you mean you'd like to have one WebServer
instance listening on multiple ports? What would be the use case for this?
This would be simple to add, I just hadn't considered it."

No, I can't think of an situation, where that would be useful. Processes listening on different ports, as you showed here:

"wc8080 := WebServer new listenOn: 8080.
 wc8888 := WebServer new listenOn: 8888."

is what I meant. And clearly WebClient can do that. I think I've been using WebClient in a certain way, where all roads lead to the class variable Default, and could not see it otherwise. Thank you for the example.

Chris