Re: [KMess-devel] Downloading MsnObjects in master (/hilight Diederik)

[Diederik v. d. B. <vd...@km...>]

Hi Sjors,

Sorry for my really later reply. I hope my input is valuable nevertheless.

There isn't much "bookkeeping" of MsnObjects. What currently happens:
  * The ChatMaster checks whether the file exists, and downloads it otherwise.
  * Things like display picture, and emoticon mappings are stored in-memory 
per-contact.

The responsability could be in the application. There is a signal 
"receivedMsnObjectAnnouncement" and the app can deside what to do. See:
  * http://trac.kmess.org/wiki/MSN%20Protocol%20Library%20Ideas
  * http://trac.kmess.org/attachment/wiki/LibKMess%20Design/kmess-network-
library.png

As for the msntransport lib, it has the protocol basics implemented,
and misses the top-level layer (for End-User-Features) to start a download.

Greetings,

Diederik


Op dinsdag 22 februari 2011 18:48:48 schreef u:
> Hi all,
> 
> I've been looking at the reason why custom emoticons are not shown yet. Now
> that the library correctly links custom emoticons to their messages
> instead of to the contacts that sent them, the behaviour of the library is
> correct. However, in the frontend, the RichTextParser still only looks at
> the contact. I've decided to leave the hack be in the frontend: it's a lot
> easier to fix it later than it is to fix it now. So, once the frontend
> receives a message with custom emoticons in it, it promptly gives the
> custom emoticon shortcuts and their MsnObjectData to the contact to hold
> again. This way, most of the frontend can still work like it did, but at
> least the library has the correct behaviour.
> 
> Then, I started looking at how the actual emoticon file is downloaded;
> let's refresh our minds. In stable, the MsnSwitchboardConnection emits a
> gotMsnObject() signal to the ChatMaster to tell it to download MsnObject
> data unless it already exists. The ChatMaster, after some checks,
> continues to start a MsnObjectTransferP2P application to get the object.
> Eventually, slotMsnObjectReceived is called, which eventually shows the
> object: it either sets it as the contact picture path, shows it as a wink,
> or adds it as the file for a custom emoticon and tells the chat window to
> 'refresh' its view.
> 
> Most of this infrastructure is gone in the master version. On one end,
> MsnChat has the gotMsnObject/startMsnObjectDownload calls commented out,
> because nothing implements those at the moment. On the other end,
> showMsnObject is commented out because it references classes like
> KMessConfig, ContactExtension and Chat to actually change stuff, which are
> in frontend code.
> 
> So we have a few things to implement.
> 
> 1. First of all, some class should get the responsibility of 'bookkeeping'
> MsnObjects: checking if they exist and are valid, and starting their
> download if they aren't. I don't think this should be MsnChat (but it
> might be a worty option); MsnSession sounds like the right class to me. 2.
> Second, there should be a class that actually does the transfer. This used
> to be MsnObjectTransferP2P, a P2PApplication, but even that base class
> doesn't exist in the library anymore. I expect something in
> contrib/msntransport will replace it, but that isn't used yet. 3. Last,
> there should be a message back from the transfer class to showMessage or
> something in the library that the download is completed.
> 
> Here, I've even assumed that we *want* the library to automatically
> download MsnObjects it doesn't know (and I've abstracted away from the
> problem that the library doesn't really have some place to store temporary
> cache files like MsnObjects yet).
> 
> Which class do you think should get responsibility of starting MsnObject
> downloads? Then at least we can make MsnChat link to that class, and we
> can put stubs there. And, (primarily to Diederik,) how is msntransport
> doing? Does it have a class to do P2P downloads? How much work will it be
> to port MsnObjectTransferP2P to, or write a similar class for
> msntransport?
> 
> Once these parts are in place, it will probably be easy to let the
> application decide to download MsnObjects if it doesn't have them, instead
> of the library deciding on itself it needs to download a MsnObject the
> application might not even use.
> 
> Sjors

-- 
 Diederik van der Boor, KMess developer
 Web: www.codingdomain.com