Thanks for the answer, at least I know I can begin without being interupted with a huge "it's the total opposite you should do"... I won't create the svn module or do the commits in new dirs, but I can start working on the files locally at least.
KaKaRoTo On Mon, 29 May 2006 17:43:36 -0400, Harry Vennik <[EMAIL PROTECTED]> wrote: > 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 -- KaKaRoTo _______________________________________________ Amsn-devel mailing list Amsn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amsn-devel
