Re: [weld-dev] A ConversationManager API

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