- Get rid of XMPP-based document transfer. It's ugly, hard on the network, and goes against the XMPP server model. HTTP will become the primary document transport. Meta tags or tags with alternate namespaces will contain an XMPP "server" JID.
- (Another approach) Consider adding a JID and/or JID-derived token to be included as an "X-JID" header (or something) in HTTP requests from a logged in client. Interesting problem: can we prove that the XMPP server has authenticated us out of band? If not, there's no point in doing it. Also, it might break the model. (JID != cookie/user info)
- Get some decent examples up and running. PollingReport.com has good figures, or I could subscribe to Gallup. (Probably contravenes their TOS.)
- Improve the serverside API, which kinda sucks right now. It should be either interfaced and static-proxied, or dynamically proxied, or EJB...
I also want to fix some things in the known problems list, (UI issues). One or two things from the roadmap, specifically allowing directives to apply to attributes and text nodes, would also be good additions.
The incomparable Smack API now understands Data Forms and Feature Negotiation, as well as Disco, so I now have the freedom to make this a lot more flexible/complicated if I wanted to.
The next release planning was based on the assumption that this would be a real app, and not a demonstrator for a set of very cool DOM extensions, but still has some weight. Some stuff in there should be done too, probably.
My end result, ten years from now, is that I want to be able to do things like: pull up a map of the world, and then chart trade deficits from one server, strategic oil reserves from another, and defense budgets and standing army sizes from yet another, all on the same map/chart, and then make those numbers dance on the resulting infographic.
Posts
