[Seaside-dev] Seaside vs I18N/L10N vs VW

[Martin Kobetic]

Philippe Marschall wrote:
>> I don't think that would work, because the rendering process is
>> forked only later in WASession>>incomingRequest: (calling
>> critical:ifError:), it's that process that we need to set up, so
>> that the rendering runs with the right 'environment'. Doing the
>> forking with a PlatformSupport call seemed like the simplest thing
>> that shouldn't cause much disruption and would provide us with a
>> place where we could put such VW specific setup code.
> 
> Then what about #responseForRequest: or #performRequest:? Do you 
> really need to know the locale before forking the process or can you 
> set it at any time?

Yep, timing would be OK with those, but I don't think I follow what you're suggesting. Adding a callback to those methods ? Calling a new block parameter or something ? I can see adding a callback from there to the new resources that we're proposing, just before performing a request for example. That would provide a lot of flexibility and should give use all we need for VW too. Does that sound OK ? 

>> Actually, what I'd prefer the most would be if Seaside didn't spawn
>> a new process at all. We already have "worker process" management
>> facilities built into our HTTP server. You can use different worker
>> allocation strategies, tune parameters etc. This fork that is
>> hardwired deep inside Seaside is killing all that. And that's in
>> addition to all the other issues that forking additional process
>> causes (the process setup issues, exceptions can't get past that
>> fork etc.). But I assume asking to change that would be even more
>> controversial.
> 
> Isn't the advantage of green threads that they are lightweight?

Well, they are light, but not weightless. When you have a system under heavy load, you can find all kinds of interesting 'pressures' that you need to deal with, and not being able to control them can be quite frustrating. Moreover based on what I read in other discussions here, the justification for this particular process seems rather weak. Forking even lightweight processes for no good reason is just plain wasteful, especially on server side. And that's again ignoring all the other issues I mentioned besides runtime costs.

> I think no one can seriously expect Cincom to donate all their i18n 
> code. But it might be that there is a simple implementation of i18n 
> with three or four classes that does only message translation and 
> would work for many cases. Everyone who wants something else could 
> still run their own or use the what the platform provides.

OK, we'll see what we can do there.

Cheers,

Martin