-- designed the flow of client-incoming and server-incoming messages:
-- filtering, switching (deciding local processing vs. delivery), and then processing or delivery
-- built out a ton of hookchains for said phases
-- implemented default fallback hooks for said phases, adhering to specs
-- annotated more of the specs, so our must-implement-specs test case has more tests
-- documented another ambiguity in the spec
-- started separting out the "Server" object from the "Vhost" object. (a server HAS 1+ vhosts)
Then we built DJabberd::Delivery::Local
Which just does local delivery. (currently just local vhost, but in future local vhost first, then local server, but injecting the message back through the "almost beginning" of the other vhost's filtering hookchain, just bypassing all XML crap, so that vhost's filtering/routing hooks still run all normally.)
The big accomplishment is that message delivery then works. Both client-incoming and server-incoming messages eventually end up in either server-process or deliver, or client-process or deliver. (so the deliver is shared, once filtering/switching is done)
So we were IMing each other from same node, and from GTalk, Jabber.org, etc.
Now that we have the delivery framework, we need to build DJabberd::Delivery::S2S so we send outgoing messages back to GTalk/Jabberg.org/etc. (we'll also be building DJabberd::Delivery::LocalCluster after that to do inter-domain delivery for a load-balanced/HA jabber installation.....) Outgoing S2S will be easy considering we already do outgoing connections for Dialback and such. Just had to build out the delivery framework first before we could even really test it.