[Delta] Iris Roadmap

[Justin Karneges]

Folks,

I hope to resume development on Iris very soon, and so I figured I'd jot down 
some plans.  First, I should say that I've been looking forward to this for a 
*long* time.  Many of the ideas below have been in my notes for years.

There are 3 major areas of Iris:
  1) networking (dns, tcp, etc)
  2) low-level xmpp (c2s, stanzas, etc)
  3) high-level xmpp (rosters, pep, etc)

I intend to focus on areas 1 & 2 for the time being.  I might eventually work 
on area 3, but that mostly depends on how well the other Psi developers 
maintain that area.  If it looks like things get stale or there's no 
innovation, then I may step in.  Otherwise, area 3 has seen a lot of action 
lately with 0.11 so I'll stay out of it.

Networking (irisnet)
-----
The goal for this area is to create a toolbox that makes implementing network 
protocols easier.  In some ways it is "cutestuff/network next-gen".  Classes 
in here won't be specific to XMPP.  Lots of code and concepts that were once 
the domain of iris/xmpp-core (e.g. auth, sasl, proxying, certificate 
handling, parsing) will probably be moved into here for reuse by all of the 
protocols we support.  Also notable will be expanded support for DNS 
(including DNS-SD) and UDP.  I'd like to also add SOCKS4, since we seem to 
get a request about that every so often.  Finally, I'll have "legacy" 
wrappers to assist in porting.  For example, there's already a drop-in 
replacement for NDns which calls NameResolver internally.

Low-level XMPP
-----
XMPP::Stream will finally have subclasses besides ClientStream.  I'm not sure 
about the class naming yet, but we essentially need subclasses for c2s, s2s, 
xmpp-over-bosh, and c2c (link-local).  I'd then like to extend the Router 
concept used in Ambrosia (and many other XMPP server implementations) to 
clients.  Instead of writing a stanza to a specific stream (currently, 
stanzas are written to a specific XMPP::Client instance which is associated 
with a single XMPP::ClientStream instance), stanzas will be sent to a Router 
object, which will then send the stanza out on the appropriate stream, 
possibly even creating the stream on demand (s2s, c2c).  XMPP::Stream objects 
may become invalid, but Router objects will never become invalid.  Router 
objects will always be operational, regardless of the connection state 
(similar to XMPP::Client), and if there is no stream to write to (or none can 
be made on demand, if appropriate) then the Router would bounce the stanza.  
It should even be conceivable to use a single Router to operate multiple 
jabber accounts, although I don't expect Psi to be written this way.  The 
Router concept will make the most sense with Link-local chat, where you 
really don't want to be thinking in terms of streams.

Phase 1
-----
The first phase of my Iris work will target the lowest levels of area 1:
  - dns
    - lookups, unicast and multicast (seems to be done)
    - service resolver abstraction (blends dns-sd and internet srv)
    - jdns (done)
    - mDNSResponder plugin (need this for dns-sd support on mac platform)
    - libidn/punycode/nameprep?  (Qt has some stuff, need to investigate)
  - network interface detection (somewhat done)
  - abstractions: ByteStream (for tcp-ish) and PacketStream (for udp-ish)
  - tcp
    - client and server
    - ack tracking for operating systems that support it
  - udp
    - client and server, 1-to-1 only
  - legacy wrappers

If anyone has a suggestion of something else that should be put at this level, 
let me know.  A couple that I'm unsure about are operating system proxy 
server detection and UPnP, but I'm thinking maybe these should be a layer 
higher.

-Justin