Sorry to reply to my own post; I was in a hurry to leave when I sent the last one, so there are a few more things I want to add.

I have put it in Services/User/Jabber/ for now. Eventually, the XMPP framework will make its way into the Frameworks directory. The last refactoring I did should make it relatively easy to create a simple IM application that is integrated into the desktop, and allow loadable bundles to add services (e.g. sending serialised objects to remote users). I want to try to keep the XMPP library the same over all platforms, but I intend to fork the application at some point, and make a portable version and an Étoilé version.

The Étoilé version will probably include some bundles that add some extra Étoilé-specific features to the framework too. For an idea of how this is done, take a look at the StanzaFactory base class and it's subclasses (IqStanzaFactory, MessageStanzaFactory and PresenceStanzaFactory) classes. The classes that parse IQ, Presence and Message stanzas (the three main XML elements defined for an XMPP stream) use singletons of these classes to determine which classes should be used to handle child elements (and which instance variable should be used to store the result. If something that is not an instance variable is specified as the value, then it pops it in an NSDictionary). The TRXMLNullHandler can be used to ignore children explicitly, and is used in the base classes for any children of unrecognised types.

Once a Message, Presence or Iq (info-query) class has been constructed from the XML stream, it is handed off to an instance of the Dispatcher class. This is conceptually similar to an NSNotificationCenter, but allows slightly finer-grained control over which things you receive.

I've tried to keep the coupling as loose as possible, to make it flexible.

The TRXMLXHTML-IMParser class should be a relatively complete parser for turning XHTML-IM into an NSAttributedString. I disabled it a while ago while looking for other bugs, but it probably wants re- enabling and testing. If you compile without the WITHOUT_XHTML_IM macro defined, then it will be enabled.

Since it's still a development version, it is full of NSLog()s. These should be removed / commented for a release build...

The XMPPConnection class has a really ugly state machine for handling various connection states, which probably needs replacing (and converting to use NSStream, not it's supported by GNUstep).

This, of course, should have read 'now,' instead of 'not.'

I started porting an old version to GNUstep, and got it to the point where everything compiled, but a bug in GORM prevented me from doing more (it wouldn't parse my headers correctly). Now GORM can read OS X .nibs, finishing off the port should be relatively easy. There is a GNUMakefile which can be used as a starting point, but don't expect it to work correctly at the moment...

You may notice a few subdirectories that are empty. These exist because files used to be divided into them but GNUMake can't (couldn't?) cope with projects that didn't have all of their source files in a single directory. When I started the GNUstep port, I had to move everything into the project root.

One last thing:
The CompareHack files shouldn't be needed on GNUstep. They are just needed to work around a bug in the Intel version of Cocoa.

Oh, and although it's been refactored a few times, this was my first OpenStep project, so be nice...

David
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to