Op maandag 29 mei 2006 23:16, schreef Youness Alaoui: > 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 ? > Yes, but too tired for a complete reply now... So, just a short reply now...
I also think that amsn2 should be a module rather than a branch. Also I like the directory layout you propose. The idea about the Capabilities seems very nice too. About the data part, I already took care of that in earlier e-mails (at least, I thought about in making the designs), but indeed, did not make that explicit. Also you are extending it to other things than we discussed (we talked about contacts/groups mainly, now you also mention things like nudges and winks), and you are right, those should have a data layer too, between the protocol and the UI. Okay, I'll reply more in-depth later. Harry > 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 _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
