From crazyboblee on February 14, 2007 11:13:57

Here's a nice description: http://evolutionarygoo.com/blog/?p=79

From kevinb9n on February 26, 2007 18:46:33

This would be awesome to have...

From kevinb9n on May 31, 2007 13:32:36

Bob, can you talk me through the design/functionality you have in mind?  Should
conversation state be compactly encoded into a url parameter?  Should it be stored in
the HTTP session identified by a key?  Or somewhere on the server outside the session
(which seems problematic since whatever the user's session failover mechanism is will
ignore this state).

How will it look for users to express when conversations begin and end, etc.?  They
can nest, right?  Details, we want details! :)

From dhanji on June 05, 2007 15:59:59

@Kevin's gtalk msg:

Hmm my impl right now requires you to inject Conversation and call begin() and end()
on it. This should be easy to abstract into a url param or whatever (I dont like
forcing url conventions on ppl, esp in these RESTful times). It is also stored in the
HttpSession (this makes appserver-replication and stuff easy).

Also a second call to begin() restarts the convo. I would love to be able to support
keyed-conversations (flows and continuations!!) but couldnt figure out how to do coz
you dont get access to the scoping annotation in a Binding.

This is still a WIP mind, not much testing around it: https://statelogic.svn.sourceforge.net/svnroot/statelogic/guice-flash-scope-test

From crazyboblee on June 05, 2007 16:19:00

Injecting Conversation and calling begin() and end() sounds reasonable to me. Our
internal implementation forces you to redirect after starting a conversation (so you
can encode the ID in the URL) and the user can't accidentally keep reloading and
starting new conversations.

We enable programmers to pass a URL to end(), and the framework will automatically
redirect to that URL if the user tries to enter the conversation after it has ended.
You might end the conversation and redirect to a confirmation page for example.

The framework should be able to handle additional error cases like when the user
requests a conversation that doesn't exist. The session may have expired for example,
and the framework should be able to detect this (we could encode the session ID in
the conversation ID) and react appropriately.

The framework should handle concurrency automatically. For example, we may only want
to let one request through in the same conversation at a time. The framework probably
shouldn't lock until the code actually uses a conversation-scoped object, and it
should take care to keep threads in the correct order (simply synchronizing isn't
enough).

It's OK to encode the conversation ID in the URL, i.e. more RESTful URLs needn't be
accommodated. URLs in the middle of conversations/wizards typically aren't important,
i.e. you don't bookmark them or otherwise visit them directly.

I don't think we need keyed conversations. Our internal code just generates a unique
ID for each conversation and only allows one conversation per request. This seems to
work well.

We should not tie this to HttpSession. At a minimum, we should make an abstract ID
available for injection so users can store conversation state manually in a database.

The framework needs to encode all URLs with the conversation ID. We should probably
rely on HttpServletResponse.encodeUrl() for this.

The framework should manage security, i.e. it should prevent users from skipping
steps. Our internal code accomplishes this by only allowing users to visit URLs which
have been encoded in the same conversation. For example, if I haven't encoded a URL
for "/foo" (via encodeUrl() or redirect) I don't allow the user to visit "/foo".

That's off the top of my head. I think I have a design document floating around
somewhere, but it's probably more geared toward users.

From dhanji on June 05, 2007 19:25:56

nice, you've got a lot cooler stuff in mind for convos. I like what you're proposing
for sure. At work we've got almost exactly that setup using spring webflow (convs
persisting in cluster cache, url param key in request etc.).

A couple of concerns: how do you know to load the conversation when the session has
ended prematurely (or lost) if you dont have a key for it (that can be tied to a
user-id for instance)?

Also the conversation id needs to be user controlled when for instance you want to do
continuations (I want to load up all active convos and choose one based on some
logic). I know you can probably get by without a user-provided key but it seems
easier with one.

I still dont like enforcing url conventions. A user should atleast be able to provide
their own override of the url encoding behavior; otherwise integrating with a
framework like JSF (has weird url system) or jsr311 becomes difficult.

post & redirect is a good pattern for any sort of action processing. I think even
tapestry/howard has seen the light on that one ;)

As I said to kevin I've not done much work on my conversation scope since Ive been
working on hibernate/jpa support ( http://www.wideplay.com/guicewebextensions2 ).

That was my 22c. =)

From dhanji on June 08, 2007 17:19:22

Also, I think starting and ending a conversation are events that should be published
somehow--there should be a way for me to hook into begin() and end() to do some init
and cleanup work of my own.

Will using guice-aop over the Conversation artifact be sufficient?

From bslesinsky on July 07, 2007 16:10:20

Correction to the above link: http://evolutionarygoo.com/blog/?p=68

From gcgdru on January 24, 2008 22:36:43

good

From hexudong08 on May 23, 2008 06:21:06

I have a look .

From bslesinsky on June 18, 2008 16:57:52

See keyed providers ( https://code.google.com/p/google-guice/issues/detail?id=211 ) for
an alternate approach to this.

From max%oizo.biz@gtempaccount.com on May 10, 2010 19:07:22

I need Flash & Conversation scopes.
Please, add it... All popular framrworks (seam etc.) already has it.

From dhanji on July 17, 2010 18:30:56

@13 Flash doesn't make any sense to me. We had it in warp-servlet and threw it out when it was migrated over to guice-servlet. Flash is supposed to exist between two requests, as a way to help the post-and-redirect pattern but which two?  It seems that this is specific to certain webapps that know when they want a flash scope, and not a generalizable solution. =(

Conversation scope may be a possibility depending on how we can work out the details so it behaves well in a cluster environment.

From christianedwardgruber on June 04, 2012 10:40:09

(No comment was entered for this change.)

Labels: Component-Servlet

From cgruber@google.com on November 18, 2013 13:02:11

(No comment was entered for this change.)

Status: Acknowledged