[weld-dev] A ConversationManager API

[Nicklas Karlsson]

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

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

>>   public abstract ConversationManager endAllConversations();
>
> Whats the use case for this?

Nothing that couldn't be achived by iterating endConversation(String)
over getLRCs().

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

> 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. 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 ;-)

-- 
---
Nik