[weld-dev] A ConversationManager API

[Pete Muir]

On 30 Jan 2010, at 19:35, Nicklas Karlsson wrote:

>>>   public abstract ConversationManager endTransientConversation();
>> 
>> I wonder if this should be destroy, not end to preserve the semantics of end as demoting a conversation
> 
> Why not. In general, this method is a bit questionable. What is the
> current conversation after this call?

Right, which comes back to William's point. I guess the answer is the that the context is not active.

> 
>>>   public abstract ConversationManager endConversation(String cid);
>> 
>> I wonder if this is needed, as you can achieve it by restoring the conversation and then calling Conversation.end()... Do you see this as a particularly common use case?
> 
> Hmm. Perhaps some sort of "destroy other than current"-loops?

What's the use case for this?

> 
>>>   public abstract ConversationManager endAllConversations();
>> 
>> Whats the use case for this?
> 
> Nothing that couldn't be achived by iterating endConversation(String)
> over getLRCs().

Yeah, I think this method is redundent.

> 
>>>   public abstract Set<String> getConversations();
>> 
>> This in the current session right? If so the javadoc should say that :-)
> 
> The spec already says conversations don't cross session boundaries ;-) OK, OK...

:-)

> 
>>>   public abstract String getNewConversationId();
>> 
>> What is the use case for this?
> 
> A conversation can inject a CM and call this on Conversation.begin().
> OTOH. The CM could get this itself if we defer it to the end of the
> request. It's probably even closer to the spec since it says that the
> cid should be constant over the request. That would of course mean
> that C.begin(String) should store the  value in some cidSuggestion
> field

Ok, this does make sense. How about generateConversationId()?

> 
>> IMO this should just check if the conversation id is in use regardless of the current conversation. This is a much simpler contract to understand.
> 
> This would also be for C -> CM integration where C.begin(String) would
> check for cid collisions.

Yeah, I think this needs some thought, as APIs where you have the word except generally mean there is a design error ;-)

> But as in the previous case. If the cid is
> checked at the end of the request this could be skipped and handled by
> the CM. But I recall you wanted real-time action in the conversation
> at one point ;-)

Yes we do.

> 
> -- 
> ---
> Nik