We need a clean way of overriding certain logic within the model (specifically one chat per remote JID)

[GoogleCodeExporter]

We have the following functionality:

When a user starts a new chat with a remote user (or group), they are first 
prompted for some metadata. This metadata is attached to each message 
packet sent from that conversation. A user can start multiple conversations 
with a single remote user (or group) with different metadata. (In the 
example attached this metadata involves an opt in/out to certain terms, but 
could in reality be anything).

The problem here is that the current Chat conversation model assumes that 
there is only ever one Chat per remote user/group. We have therefore had to 
import portions of Emite and Hablar into our code base in order to override 
this which is obviously non-ideal.

We have therefore started to investigate a method by which we could adapt 
the Emite and Hablar core so that we can extend the funtionality without 
having to copy/paste chunks of code. This should also be done in a way such 
that the existing api is intact so as not to break existing code.

There is a brief design proposal in the attached documentation.

I'm raising this issue to start the conversation about how we should go 
about cleaning up our implementation.

Original issue reported on code.google.com by ashward....@gmail.com on 30 Apr 2010 at 10:12

Attachments:

• emite_proposal.rtf
• chat_proposal.pdf
• chat_manager_proposal.pdf

[GoogleCodeExporter]

This was previously Issue #153 which I've now closed.

Original comment by ashward....@gmail.com on 30 Apr 2010 at 10:15

[GoogleCodeExporter]

As I understand you need certain extension points to modify the behaviour of 
ChatManagers and Chats 
(including RoomManagers and Rooms) without replacing them.

I think most of this functionallity is already implemented. 

Chats (the Chat interface: PairChat and Rooms included) already have some 
usefull methods:
1) getData and setData allows to associate some objects to certain chat (the 
"metadata")
2) onBeforeReceived and onBeforeSend allows to "intercept" the message and 
modify it before any of both 
actions
I think this four methods could be used to implement two of the problems:
2. Applies packet extension metadata to packets prior to sending, based on the 
initialised metadata.
3. Adds behaviour to packets based on the extended metadata.

Also, ChatManager (the interface: PairChatManager and RoomManager included) has 
the onChatCreated 
method that allows to "1. Intercepts chat creation to initialise packet 
extension metadata."

The only extension point I miss is a way to (easily) replace the logic to 
determine wherever a packets belongs 
to one conversation or another, but given your documents, I don't think this is 
a requirement for you...

Am I missing something?

Original comment by danigb on 3 May 2010 at 9:11

[GoogleCodeExporter]

Rethinking about your requirments, prorably you will need an easy way to change 
the way the managers selects 
one chat or another as target of a message (but it's the only missing required 
functionallity i can think about). 
Any other thoughts?

Also, there's probably a better wat to implement those extensions points... any 
suggestion?
Regards
Dani

Original comment by danigb on 3 May 2010 at 10:46

[GoogleCodeExporter]

Attached is a proposed (simplified) sequence diagram for message receipt to 
demonstrate the chat manager decorators

Original comment by ashward....@gmail.com on 20 Jul 2010 at 7:57

Attachments:

• sequence1.pdf

[GoogleCodeExporter]

Suggested solution:

* Create a new ChatMetadata to encapsulate... ehem... the chat metadata

class ChatMetadata {
   private final HashMap<Class<?>, Object> data;
   getData/setData
}

it also involves the deprecation of the getData/setData methods in Chat and add 
a new method: getMetadata();

* Create a new ChatProviderStrategy and RoomProviderStrategy:
interface ChatProviderStrategy {
  Chat get(XmppUri uri, ChatMetadata metadata);
  Chat create(xmppUri uri, ChatMetadata metadata);
}

interface RoomProviderStrategy extends ChatProviderStrategy {
// same methods signatures with Room instead of Chat as return value
// it allows to use RoomProviders as ChatProviders if necessary
}

* Let ChatManager and RoomManager delegate on ProviderStrategy instances to 
easily change one strategy for another

* add a ChatManager.open(XmmpUri uri, ChatMetadata metadata) method

* Add a onBeforeInvitationSend method to Rooms in order to intercept and modify 
the invitation to a new room with the information of the ChatMetadata 

Original comment by danigb on 20 Jul 2010 at 12:38

[GoogleCodeExporter]

Original comment by danigb on 13 Aug 2010 at 6:15

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision r1585.

Original comment by danigb on 19 Aug 2010 at 10:20

• Changed state: Fixed