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

[Philippe Marschall]

2007/10/11, Martin Kobetic <mkobetic at cincom.com>:
> Philippe Marschall wrote:
> > 2007/10/10, Martin Kobetic <mkobetic at cincom.com>:
> >> 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.
> >
> > I was just wondering why something like WASession >> #handleRequest:
> > wouldn't work.
>
> 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?

> 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?

> >> 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 ?
> >
> > Well doing changes in Seaside that benefit only one dialect are a bit
> >  hard to justify.
>
> But that's what I hope I'm trying to avoid here. I'm describing what it took to plug into existing VW facitilies and hoping to come to some sort of agreement on what would be a reasonable set of hooks that would fit not just VW needs but hopefully needs of all other dialects as well. I realize that's a bit hard to judge for dialects that don't have any I18N facilities yet, but that's the reality we're in now. We definitely do think about any change we propose and consider the impact it may have on other dialects. I think the changes that I proposed here are fairly minimal both in size and disruptiveness. They won't give full I18N solution to Squeak, but that's a different issue that I don't think we can solve now. I certainly don't have the mandate to donate VW's I18N facilities to Seaside, and I'm not even sure that would be the best solution either. I believe that for any dialect that already has I18N facilities it's preferable to be able to use them in Seaside as well, rat
> her than offering a different mechanism in every framework to their users.

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.

Cheers
Philippe

> Anyway, if we don't feel at this point that we can come up with the right set of hooks that will fit all, that's fair enough. Soon we should be able to submit code for 'session resources' that I mentioned earlier. It's quite possible that we'll be able to address all VW's I18N needs in that context, all we really need is a callback in the context of the rendering process that happens prior to rendering. It shouldn't be hard to come up with a generally useful callback that will fit the need. We'll see.
>
> Cheers,
>
> Martin
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>