3:03 p.m.
> - Primarily for applications other than standalone desktop apps
which
> happen to have multiple user support and/or are server based, but no
> HTTP/Servlet based front-end. For example a Trading platform using FIX
> protocol. This almost makes me think that non Servlet scopes belong
> in a
> separate extension - something that could be used in conjunction with
> EJB Lite. Thinking aloud a bit there.
I'm no expert on desktop apps, but I can see that session might make
sense here - do you have multiple users logged in at the same time?
Yeah let me try to explain myself a bit more clearly.
So for a standalone desktop app there would only be one user at any
given time. In which case, having to deal with session scope and even
request scope seems a bit naff. But as the Numberguess example shows
there's potential value in having conversation scope and application
scope.
But take as an example a trading platform which runs as a service in a
dark room somewhere with a purely message based interface (eg: FIX
protocol). This is obviously not a desktop app, nor does it have any
servlet or web based functionality. However it will still have the
notion of multiple users logging in concurrently, sending through
requests and probably long running conversations as well, for things
like trade negotiations. So in this case we could make use of all 3
scopes (session, conversation and request).
Pretty straightforward, I think we're all agreed so far. So finally ...
Imagine implementing a swing based front-end to this trading platform as
a desktop app. If you as a developer are provided with a conversation
scope to code against on both the server and client side, is that a good
thing, or could things start to get a bit confusing? If you could align
the conversations easily between the client and server I think it would
be a good thing. At the very least, on the client side you could make
your conversationId conversation scoped ;).
Thoughts?
Pete.
With conversation - we can code around this I think...
>
>
> What are your thoughts on these?
>
>
>> Yes, I need to finish the lifeycle SPI stuff, I got the idea straight
>> now :-)
>> My idea is that lifecycle just has methods to do the relevant things
>> here, and you don't need to worry about things like conversation
>> manager...
>>
>> Let me do this work (will be the week after next I think), and then
>> we
>> can review?
>
> Sounds good!
>
>>> I would like to clean up the syntax for starting requests because
>>> it's
>>> obviously pretty ugly and verbose right now. Maybe some kind of
>>> annotation and interceptor pair perhaps? And possibly some
>>> Swing-specific helpers to make it easy to attach the Request context
>>> to
>>> a button click? Making this sort of stuff more transparent is my
>>> next
>>> goal.
>
> I guess, as hinted above, probably doing away with Request and Session
> scope, or somehow making it completely transparent at least is the way
> forward here. Agree?
Yes
>
>
> Cheers,
>
> Pete.
>
>>>
>>> Let me know what you think, anyone. Cheers.
>>>
>>>
>>> Pete.
>>>
>>>
>>>>>
>>>>>
>>>>> Finally, I'm /experimenting/ with enabling and using Request,
>>>>> Session
>>>>> and Conversation scopes/contexts in SE. If you're interested in
>>>>> seeing
>>>>> the working code I've got the changes to core, SE and the
number
>>>>> guess
>>>>> example ready to check in to separate branches. Happy to discuss
>>>>> this
>>>>> further if anyone is interested/curious.
>>>>
>>>> Perhaps send a patch out for review (or attach to a JIRA issue?)
>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pete.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> webbeans-dev mailing list
>>>>> webbeans-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>>>>
>>>> --
>>>> Pete Muir
>>>> http://www.seamframework.org
>>>> http://in.relation.to/Bloggers/Pete
>>>>
>>> <se-contexts.diff>
>>
>> --
>> Pete Muir
>> http://www.seamframework.org
>> http://in.relation.to/Bloggers/Pete
>>
>
>
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete