Hello Alexander,

On Thu, Sep 17, 2009 at 2:47 PM, Alexander Tsvyashchenko
<[email protected]>wrote:

> Hello Sandip,
>
> On Thu, 17 Sep 2009 12:47:23 +0530, Sandip Nemade <[email protected]>
> wrote:
>
> > consider a scenario :
> > 1) whenever user sends a first message to the contact it goes to the
> > bare jid of the contact. This activity creates one collection with the
> > bare jid of the contact.
> > 2) After contact replies for the first message, user's client sends
> > message to the full jid of the contact. This activity should also create
>
> > one collection as client might retrieve collection by specifying this
> > particular full jid of the contact.
> > 3) Suppose a contact replies from some other resource than used in point
>
> > 2, then this again should create a collection for same reason specified
> > in point 2 of this scenario.
> >
> > This unnecessarily will create so many collections with the same
> contact.
>
> Yes, if auto-archiving is implemented in the way you describe. However, it
> should not ;-)
>
> Please have a look at
> http://www.ndl.kiev.ua/content/xep-136-and-xep-59-implementation-comments,
> and specifically for "resource modification when auto archiving" /
> "conversation tracking" topic (most of the other comments on that page are
> obsolete now, but this one still holds).
>
> > How useful(practical) is it to store the separate collections based on
> > different full jid's of the same contact?
>
> I would say - both useful and practical: "useful" because I might be
> interested in knowing which resource was used for that particular
> conversation ("I remember I was chatting with Juliet when she was at work,
> so I'm going to list only collections with [email protected]/Work") and
> "practical" - because with proper conversations tracking (preferrably based
> on threads if clients support that, but even simpler heuristic tracking
> typically works well enough) there are no more conversations created than
> necessary.
>
> --
> Good luck!                                     Alexander
>

I agree with your argument; but
1.) it is very difficult to remember all the resources of each roster items,
2.) when it comes to end user there is very less possibility that a user
will modify its resources hence he/she might have a default resource name as
per the implementation of the client being used,
3.) if I want to retrieve all the archived messages with [email protected] during
the whole day when abc has used multiple resources on that day viz.
[email protected]/home (in morning), [email protected]/work (in afternoon),
[email protected]/home (in evening again); in this case it is very difficult to
retrieve all the collection or the archived messages in proper order.

-- 
Regards,
Mittal Thakkar

Reply via email to