Xinf Architecture
Xinf's goal is to provide a unified, SVG-oriented API that allows you to write graphical applications (and games) in haXe that will run on the three target runtime environments.
Xinferno
Xinf's approach is to create an intermediate rendering protocol through which all instructions to render graphical elements are funneled - Xinferno. The aim is to keep this protocol as simple as possible while allowing efficient rendering of near-compliant SVG content. It is initially a one-way protocol, amongst other goals to allow implementations via network connections or storage in files.
Xinferno is not really documented, but it should be simple enough that understanding it should be possible by looking at the main interface definition. The key to efficient rendering are the StartObject/EndObject/ShowObject which assume the existence of a graphical object model on the client side.
Xinferno additionally provides a Runtime abstraction to allow for tasks like registering for events. Events that relate to specific graphical objects (like mouseDown) carry the numeric object ID to allow association.
For most things, the flash and xinfinity implementations should be up to par, while the Javascript implementation is (partially neccessarily) lacking behind.
Xinfinity
A major effort within the Xinf project is the creation of the "native" cross-platform runtime - Xinfinity. Thanks to (standing on the shoulders of giants) a number of excellent open-source projects, the effort is less heroic than it might seem.
Xinfinity does not currently come in some 'player'-like form, but instead as a bundle of neko-based haxelibs that allow the compilation to a neko binary that will execute on your system. This might change later.
Xinfinity also is not currently documented; but i wouldn't really know what to document - it implements the Xinferno protocol and triggers events. When Xinfinity is stable enough that it makes sense to produce a player application, or create application bundles for distribution, Documentation should follow.
Xinfony
Your major contact point when using Xinf will be the Xinfony API. It provides most (if not all) objects defined in the SVG specifications, and structures to handle XML deserialization and CSS style.
Contrary to the "pure" Xinferno approach described above, there are thoughts to have a direct Xinfony implementation for the flash target. That's why the classes in xinf.ony provide the general structure, while in xinf.ony.erno, you can find the Xinferno implementations.
Xinfony is the part of xinf that really needs some kinds of documentation. I've recently documented most classes in the API reference, and there are some Examples, but some general introductions are still missing (and the API ref is not complete). Please bear with me and meanwhile help yourself by looking at the sources. You can also ask questions on the mailing list.
More?
There might be other interesting pages in the wiki, especially the ones starting with "Xinf" or "Neko":
Do I need to know all that?
Not neccessarily. As an applications developer, you'd usually use mostly xinf.ony.* and some helper stuff. Look at Examples and API docs.
