Re: [reSIProcate] architecture of telepahy-resiprocate text messages

[Mateus Bellomo <mateusbellomo@xxxxxxxxx>]

I've tried something in the line Scott proposed but I'm having some trouble to make it work:

- I've make resip/recon/ConversationManager extend ServerPagerMessageHandler;

- I've put a virtual void onMessageReceived() method at resip/recon/ConversationManager;

- since apps/telepathy/MyConversationManager extends resip/recon/ConversationManager, it should implement the onMessageReceived() properly.

- at resip/recon/UserAgent I've done mDum.setServerPagerMessageHandler(myConversationManager), and this myConversationManager is a apps/telepathy/MyConversationManager type.

the problem is this myConversationManager type is std::auto_ptr<MyConversationManager> and I need to connect a signal coming out of apps/telepathy/MyConversationManager to a slot from apps/telepathy/Connection.

Do you think it's ok to change the type from this:

   std::auto_ptr<MyConversationManager> myConversationManager;

to this:

   tr::MyConversationManager* myConversationManager;

2016-07-17 15:09 GMT-03:00 <slgodin@xxxxxxxxx>:

The APIs exposed to users should be in the ConversaManager.  Ideally we would want to have the ability to create an instant messaging conversation type that can contain 2 or more participants.  Perhaps the first version would only support 2 participants.  Someday this could support MSRP.

Lower level implementation will be required in the UserAgent class and perhaps some other new classes.  See dum/test/basicMessage for an example of how to use client and server pager message classes of DUM.

Scott

Sent from my iPhone

> On Jul 17, 2016, at 12:53 PM, Daniel Pocock <daniel@xxxxxxxxxx> wrote:
>
>
>
>> On 16/07/16 15:23, Mateus Bellomo wrote:
>> Hello,
>>
>> I've implemented methods from send/receive text messages for
>> telepathy-resiprocate. By now this functionality is implemented at
>> apps/telepathy/TextChannel but I don't think this is good because it is
>> mixing telepathy implementation with resip/recon API.
>>
>> I think this is not where this implementation supposed to be. My guess
>> is that it should be at resip/recon but I don't know specifically in
>> which class. So this are the options I thought:
>>
>> 1) put it on resip/recon/ConversationManager but I would need
>> resip::DialogUsageManager to send the SIP messages and this is not
>> available there.
>>
>> 2) put it on resip/recon/UserAgent, that has all the information that
>> TextChannel will need, but as it says at [1] this class purpose is
>> related to conversation state.
>
>
> My initial impression is that what you describes fits within the scope
> of a User Agent, so the UserAgent class may be the best choice for
> reSIProcate-specific aspects of this work.
>
>
>> 3) create another class at resip/recon API that handles only text
>> message functionality.
>>
>> Any tips and ideas would be great.
>>
>> Thanks.
>>
>> [1]
>> https://github.com/resiprocate/resiprocate/blob/master/resip/recon/UserAgent.hxx#L40
>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel@xxxxxxxxxxxxxxx
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel