Op zaterdag 27 mei 2006 10:25, schreef Youness Alaoui: > Hi, > I wanted a separate mail to explain some more the design I have in mind, > don't worry it will be fast since I'm tired :p > I'm thinking about having a new amsn2 module, in which this whole new cl > thing would go, it should be compatible with amsn1 code, so we could plug > it in and out as much as we want. first my idea is to have some structure > like this : Hmm, the code-compatibility with amsn1 is a difficult thing. It would imply a lot of additions to amsn1, that are not really needed there, and may slow it down unnecessarily. If we really need to use amsn1 code for some things, maybe we'd better have it wrapped in some connector component to make it compatible with the amsn2 core. I think that we should basically start all from scratch, and copy/paste usable code fragments from amsn1 along the way.
For the protocol, whe should use Telepathy from the very start. Please take care of that in the event framework. The signals from telepathy and the events in amsn should be compatible enough to prevent telepathy2amsn.tcl from becoming monster-code. > > amsn2 > +---- GUI > | +---- clgroup.tcl > | +---- clcontact.tcl > | +---- clwidget.tcl > +---- Data > | +---- account.tcl > | +---- group.tcl > | +---- contact.tcl > | +---- groupmanager.tcl > | +---- eventsystem.tcl > +---- Protocol > | +---- telepathy2amsn.tcl > | +---- telepathy > | +------- ?????? > +---- Core > +---- ???? Please follow a clear rule fore capitalizing... I think the telepathy subfolder in Protocol should be named Telepathy then ;-) For the rest: nice layout for now, only some stuff may move into some subfolders. > > > We could divide into more subdirs.. the protocol dir could have the > msnp13.tcl file, the msncam.tcl, msnp2p.tcl, etc... the GUI could have a > Dialogs subdir with all our dialogs (add new smiley, add group, add > contact, check for newer version, etc...), and a Preferences subdir for > our preferences window for example... or it could go into Dialogs > The Data is only to store data For protocol, I think that it is more likely to be: Protocol +---Farsight | +--- ??? // any farsight stuff we need to include +---Telepathy | +--- ??? // any telepathy stuff we need to include +---telepathy2amsn.tcl // connector between telepathy and the amsn core +---farsight2amsn.tcl // connector between farsight and the amsn core In the Telepathy subdir may also be the msn protocol connection manager for telepathy, if that needs to be in our package. We may also have a connector for amsn1 protocol stuff here, if we want to have it as a possible protocol backend instead of Telepathy. For the GUI, I think we should use some XML2GUI stuff like we wanted at first. I am most willing to code it, and think of having it compatible with something existing, if there is anything good enough. Maybe it will not even be necessary to code it from scratch. I have not yet investigated it in-depth, but I want to do that soon. In the GUI dir we may then have subfolders like: - Engine (the actual XML2GUI component) - Widgets (any specialized widgets) - XML (the xml files, maybe in some subdirs) So please, try to work out the core first, and do not hesitate to do basic GUI stuff to allow testing, but fine-tuning GUI is not wanted in this phase, since it may be replaced (but things like the contactlist stuff will probably stay, it may just need some reworking to make it compatible). > the Protocol dir could be used in order to hook the new data and gui to > the current amsn, until the MSN connection manager for telepathy is > created, in the meantime, if our design is good enough, I think we should > be able to use the jabber connection manager instead of MSN without even > noticing the difference... 100% agree. > This reminds me!!!! I thought about an intermediate class that we'd call > Capabilities.. damn, wait, I first need to say something else... > ok, so far, we've always been talking about "separate the protocol and the > GUI, separate the protocol and the GUI", but we never talked about the > data in itself... if the protocol sends us "hey, you have a new contact > named [EMAIL PROTECTED]" what do you want to do with it ? you want the GUI > to catch that then what ? show it ? then how you update it ? you have to > keep stored somewhere who is who, if he's blocked etc... that's what we've > been talking in the other thread, kind of... > now, if we abstract the data from the GUI, it means we could have ANY GUI, > it would query our common interface/API for the Data, so it will always > know what your account is, etc... Yes, that is exactly how I think it should be. The core doesn't care about protocols, neither does it care about the UI, it just provides methods to manage data, and events as a means to notify about (intended) changes of data. > it abstracts the protocol into an API (to quote Harry), and the protocol > underlying there ? who knows what it is, could be msn, could be jabber, as > long as a 'contact' is a 'contact' and a groupmanager is a groupmanager... > Now, here's when we enter the big game, does jabber have winks ? I don't > know (I never used/tried/seen jabber, so no idea, but let's assume > everything I say is true), assuming it doesn't have winks, cool, so our > Data/winks.tcl file will not be used (don't get it wrong, it's not the > implementation of the winks in that file, NOT AT ALL.. it's only > abstracting the protocol into an API, so you actually receive an event > WinkReceived, and you get a 'wink' object in argument to which you do > [$wink getDestination] or [$wink getWinkAsFlashMovie] or [$wink > getWinkAsMpeg] (or Gif), or [$wink doYouSupportGifs] or [$wink > getWinkPreview], etc...), ok you understand ? our poor winks.tcl won't be > used in jabber, but oh well, assuming jabber has winks, but it's mpeg > movies, not flash movies.. so we should call getWinkAsMpeg not > getWinkAsFlashMovie... oh, so confusing... ok, assume we have no winks in > jabber but we have something else that is nudges, and MSN doesn't support > nudges (I know, it does, but assume I'm all mighty), so your > Data/nudge.tcl (again, only abstracted info about the nudge, like the > destination, the received time, whatever... it's not the protocol nor the > GUI implementation of it)... > so your GUI, it doesn't know what to do.. you're chatting with a user, you > send a wink, you get an error, you nudge, no prob, with another user, the > winks work, the nudges don't... (assuming you have one big contact list > managing multiple $account objects from different protocols)... so what do > you do in that case ? > oh, that's where my Capabilities class comes in place. you open the > chatwinow object, it has a reference to a contact, then it does > set account [$contact cget -parent] > set protocol [$account cget -protocol] > set caps [$protocol getCapabiltiies] > set enableNudgeButton [$caps supportsNudge] > > this is a very explicit example, but the Capabilities object should be > used for almost everything, to know if you have the right to block a user > or not for example (assuming jabber doesn't support blocking a contact), > if you have the right to leave an offline message, etc... > it's Capabilities, but can be considered, in a java perspective, as a > SecurityManager (although I know very little in that domain), it tells you > what you can do or not, it's specific to the protocol, not an account, nor > a contact. Al this is really a perfect idea! > > What do you think ? I know this design is very poor so far, which is why > I'm sending it... hoping you'll send meaningfull comments! It is a very good start! > > Thanks all, > Youness. > > > > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
