On 30 Jan 2010, at 19:35, Nicklas Karlsson wrote:
>> public abstract ConversationManager
> 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)
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
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.