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
