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