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

[Martin Kobetic]

Philippe Marschall wrote:
>> 2) Every request eventually goes through
>> WAProcessMonitor>>critical:ifError:, which forks an additional
>> process for request execution. Because of that we need to pass any
>> process settings (like #locale) to the newly spawned process.
>> Arguably it might make sense to modify #fork to pass these
>> automatically, however that would be a backward incompatible change
>> in VW (currently new process doesn't inherit the environment of the
>> parent process). What I'd like to propose instead is replacing the
>> call to #fork with a SeasidePlatformSupport call. That way we can
>> put in any additional initializations as necessary. As it is we
>> have to override WAProcessMonitor>>critical:ifError: directly. Is
>> there any chance to agree on something like that ?
> 
> Do you really need to set the locale that early? Won't any later
> point do as well?

I'm not sure what exact point do you mean. If you mean the point when #critical:ifError: is invoked, it doesn't get any later than that (at least currently) from the point of view of the HTTP server integrating with Seaside. At that point control was already passed to Seaside and we won't get it back until the request execution is over. We certainly need the process to be all set up and ready when the rendering starts, so the window of opportunity that we have is from the point the process is created in #critical:ifError: until rendering is invoked. At the moment I don't see any other requirements suggesting otherwise, so presumably if we get the chance to finish the process setup at any time during that window, that would be fine. What are you thinking about ? Some sort of callback that would be invoked in the context of the new rendering process before rendering actually starts ? Assuming we can get to the session we could certainly do the Locale setup that way too.

> In Squeak I'm only aware of NaturalLanguageTranslator which wouldn't 
> work for Seaside. For Gemstone I'm aware of nothing. So right now 
> everything we do here is VW specific unless someone wants to write or
>  donate code. This by the way would make an exceptional good
> candidate for a module in Seaside 2.9.

VisualAge definitely has I18N facilities, and it sounds like they're working on their Seaside support as well. I was also wondering if Dolphin has something for that. We don't want to cause any controversy by doing something that might seem like we're trying to push VW specific idioms into Seaside. That's why I would like to hear what people expect I18N to look like in Seaside.

So do I read you right, are you saying that because of the lack of I18N support on some dialects you'd prefer Seaside to have its  own I18N module ?

>> 2) How should locale be represented in Seaside session? The above
>> scheme uses WALocalizedSession subclass with an inst var holding a
>> Symbol. In previous discussions here we mentioned potentially
>> adding a Locale object, which is fine too, however if we're after
>> supporting dialect specific i18n methods then the Seaside Locale
>> object will most likely get simply mapped to a platform specific
>> Locale object pretty quickly. In which case it doesn't really
>> provide much advantage over the Symbol. Any thoughts ?
> 
> We live by objects, we die by objects. Symbols are simply not
> objects. See announcements for an analogy.

Sure, we can easily turn the Symbol into a WALocale or something. It will be light at first but we'll see if it gets more substance over time.

>> 3) Subclassing Session. WALocalizedSession provides the possibility
>> for a component to opt out of i18n support. However modeling this
>> using session subclasses causes problems when you need to combine
>> several different, optional features, e.g. WALocalizedSession vs
>> WAGlorpSession (for persistence). We'd like to propose adding
>> generic "resource" support to WASession allowing to attach
>> arbitrary bits of information to sessions. It should be a bit more
>> than plain "property dictionary" kind of thing. Some "resources"
>> would probably find it useful if they were notified when the
>> session expires, and there are probably other events that might be
>> useful for other resource types. Any thoughts on this one ?
> 
> Again it would help if you have more users for this than VW. Like 
> Magma or Gemstone for example. And it's always simpler to talk about 
> actual code.

Fair enough, code will follow. I just wanted to gauge any dislike for the idea first.
As far as more examples go, we're already running into a clash with WALocalizedSession vs WAGlorpSession. I assumed others had run into conflicts with session subclasses too. Or is that not so common ?

Cheers,

Martin