Hi Roelof, After the not-to-be-taken-serious reply to Sanders mail, I'll now really discuss your work. First of all, I think you made a good abstraction of the MSN protocol, so you understand its concepts, which is a very important thing of course, will you ever complete this project successfully.
Unfortunately however, you seem to have forgotten about Telepathy somehow... Not only is the word 'Telepathy' nowhere in your document except in the title, also there is not even a little similarity between the interfaces specified by Telepathy, and those that you propose. So, I'm sorry to say, but it won't work this way.... Then, another problem, is that your design does not display any notion of object oriented programming... or it would be the connection parameter that's always there, and could be interpreted as the 'reference to self' (called 'this' in most OO languages). But even if interpreted that way, it does not make sense to let a connection object handle groups for example. (Although on the Telepathy side you'll need to do a few things that make equal little sense, simply because Telepathy happens to be designed that way.) Why not define some classes? (Yes, I know, there is no such thing as a 'class' in C... But that is where GLib drops in by providing a specified way to simulate classes using structs.) Telepathy defines some classes: - ConnectionManager - Connection - Channel For Channel Telepathy also defines some subclasses that represent some specific type of Channel (Text, StreamingMedia, ContactList). Now the MSN protocol abstraction needs to be designed such that it will be easy to map its classes/objects to the Telepathy ones, but not a 1-to-1 mapping. E.g.: MSNP SB connections may seem to match the Channels in Telepathy, but that is only a partial match. An SB connection == a channel of type Text, but there is no SB connection matching the ContactList or StreamingMedia channel, while MSNP has both a Contactlist and Streaming Media support... The clue is to design some set of classes that reflect the entities involved in the MSN protocol, and than have both sets of classes use one another to do their jobs. So you'll have 2 implementation layers: - Implementation of DBUS objects cf. Telepathy specification (http://telepathy.freedesktop.org/spec.html) using GLib + libdbus, as described in http://dbus.freedesktop.org/doc/dbus-tutorial.html - The MSN protocol layer implements all MSN protocol functionality, providing a class for every entity in the context. Theoretically, most clean would be to add a thin layer of glue between these to have them loosely coupled, but in this case the whole thing is glue already (between Telepathy and MSNP), and thus it is better to have both parts call each other directly. (I never saw a 2K glue stick well without mixing the two components :-P) About your questions: they are not really relevant anymore, given the above, except for the first one. Q: What to do with server-initiated messages? A: Just drop the distinction between server-initiated and client-initiated, and instead of that regard outgoing messages as commands, and incoming messages as notifications. Effectively, if any application (e.g. aMSN) calls libmsn via D-BUS, this will generate an MSN command (if some action from the server is needed), and if any MSNP message arrives that the user-level application might need to know about, a D-BUS signal is emitted cf. the Telepathy specification, and the application will be listening for it if it needs that specific type of notification. So, for adding a contact (assuming successful operation): - Application calls the AddMembers(au:contacts, s:message) method of the ContactList channel. - The ContactList channel implementation of libmsn will generate and send an MSNP message to add the contact. - The MSN Messenger server replies that the contact is added - The libmsn ContactList channel broadcasts the MembersChanged(s:message, au:added, au:removed, au:local_pending, au:remote_pending) signal on D-BUS. And for a contact state change: - The MSN Messenger server sends a message to announce the state change - The libmsn Connection object receives the message and broadcasts a PresenceUpdate(a{u(ua{sa{sv}})}:presence) signal on D-BUS. Now, I hope this helps you. And don't hesitate to ask anything! Harry Op vrijdag 14 juli 2006 18:03, schreef roelof: > Hi everyone, > > I've been quiet for some time, reading about Telepathy, the MSNP13 > protocol and dbus. Things become more and more clear in my head (it was > quite a jungle of all new terms, techniques, frameworks, etc. ;-)). I've > made a first draft of what the msnlib design (API) will look like, I > appreciate comments on it very much! The msnlib should communicate with > the msn network (using the MSNP13 protocol) on the one side and the > other side with the telepathy objects (connection manager, connections, > channels) and should be used for aMSN2. > I've a few questions on the end of the attached document. Maybe someone > can help me with it. > > Roelof ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
