no answers on this subject ? I'm still waiting for everyone's feedback on this so I can start a bit of code... I have some code done, but I don't want to commit it... Harry, u there ?
KKRT On Sat, 27 May 2006 04:25:06 -0400, Youness Alaoui <[EMAIL PROTECTED]> wrote: > 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 : > > amsn2 > | > +---- GUI > | | > | +---- clgroup.tcl > | +---- clcontact.tcl > | +---- clwidget.tcl > | > +---- Data > | | > | +---- account.tcl > | +---- group.tcl > | +---- contact.tcl > | +---- groupmanager.tcl > | +---- eventsystem.tcl > | > +---- Protocol > | | > | +---- telepathy2amsn.tcl > | +---- telepathy > | | > | +------- ?????? > | > +---- Core > | > +---- ???? > > > 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 > 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... > 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... > 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. > > 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! > > Thanks all, > Youness. > > > > _______________________________________________ > Amsn-devel mailing list > Amsn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amsn-devel -- KaKaRoTo _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
