SWF / MVC write-up

[Tom Zeller]

>>> I think we obviously need to discuss and reinforce or change the
>>>original
>>> design choice, and then decide what we need to build as a result.
>>
>>What do you mean by original design choice ?
>>
>>I think you mean not serializing (supporting clustering) within a flow.
>
> Yes. My recollection was that the decision was made (without much input
> from me) because of the need to retrofit a lot of code, and because of the
> burden it would impose on being able to add useful things to the tree
> based on functional need and not with an eye on the ability to serialize
> it efficiently.
>
> I do know that we considered it a key issue at the time and it was
> probably the major factor in deciding how to proceed with the design.

Okay, it seems we are remembering and talking about the same thing.

> *If* it's just a matter of implementing essentially our own in-memory
> lookup of the conversations so that the container session isn't involved,
> then I don't think it's a lot of code to write. And the implications were
> understood, it means you have to do sticky load balancing, as is required
> today in many cases.
>
> But the SWF code is pretty convoluted and it was hard to tell from reading
> it whether overriding the ConversationManager is really the only change
> needed.

I'll probably do some more investigating. The SWF Javadoc was encouraging.

> PS. On a good note, the fall-through to JSP from Velocity works. I don't
> know why it didn't seem to work when I tried it, I did the same things. So
> we don't have to predefine the tempates we use. I'll update my page.

Just FYI, I had a similar experience, and decided that Velocity knew
how to render JSP, but did not pursue.