Xinf Is Not Flash

WARNING: out of date

XinfArchitecture might much better describe what Xinf is up to.

0) What is 'xinf'?

The xinf (pronounced: 'sinf, acronym for "xinf is not flash") project aims to provide a unified platform for cross-runtime graphics development. It will enable you to develop graphical interfaces and "rich internet applications" that run on the Adobe Flash Player, within web browsers supporting JavaScript?, and on a cross-platform player built on neko and OpenGL, from one and the same codebase. Most of the cross-runtime magic is provided by Nicolas Cannasse's "haXe" language and compiler. Xinf will leverage this wonderful invention by providing three core components:

• xinfinity - a cross-platform (Windows, MacOSX, Linux and friends) 'player' application running on the neko virtual machine, utilizing OpenGL and other open-source libraries.
• xinfony - an API/implementation that provides various (mostly graphical) primitives that abstract away most differences between the target runtimes. xinfony will be split into a core, providing the basic primitives that will run reliably on all runtimes, and modules that provide either higher-level functionality, or functions that are not available on all target runtimes.
• xinful - a XUL-like XML dialect and API/implementation of user interface widgets.
• xnf - the "xinf native format" (or so)- a compact file format to carry data, images and code to be run by the xinfinity player.

Or, in the words of Mark Winterhalder:

Nicolas' haXe makes it possible to write code for different platforms. However, for interface stuff it is still necessary to adjust parts of the code to the specifics of each targeted platform. That doesn't only apply to projects that target different platforms at a time, but e.g. for GUI widgets. That's how I understand Xinfony, as a compatibility layer where the specifics are hidden behind. Xinful would be the next step on top of that, GUI widgets based on Xinfony that work the same on every platform. So, at least in theory, something written in haXe and using Xinfony (or even Xinful) could be published for the FP and JavaScript? (for both FF and that other browser) without any changes. Widgets based on Xinfony could be used by non-haXe users, too, in their favorite environment, be it AS2, AS3 (once haXe can target FP9), or javascript.

So, this is about re-use, coming together to agree on a standard that

works on all platforms.

Xinfinity, while it can use Xinfony-based classes/widgets, would work as an independent platform. This is interesting for places the FP can't go, like [your favorite obscure OS or platform here], doesn't like to go (not easily distributable due to license restrictions), or isn't particularly welcome (pure FOSS environments). It is also interesting for all the standard open source reasons, it is extendable, can be modified to your needs, and so on. In a way, it's a way to support a piece of open source infrastructure without giving up support for your mainstream users of a proprietary plugin, since it can be used as a fallback (serve an SWF if XNF isn't supported).

If you want even more, there have been some fundamental discussions on the mailing list already. See this thread.

1) What state is xinf in? What is the timeframe for development?

xinf is at a very early state of development. xinfinity and xinfony are both in a proof-of-concept stage, but might approach usability soon. Development of xinful and xnf hasn't started yet, and indeed they might change in their whole concept. There is no fixed timeframe - xinf is currently a single-person project, and as such heavily depends on that person's personal resources. You can speed up xinf development by helping in various ways - see 4.

That said, here are my next steps:

• completion of xinfony-core to provide colored rectangles, images, text, mouse and keyboard events.
• consolidation and completion of the preliminary xinfinity player to run that api.
• automated and interactive graphical testing framework (linux only)
• start of development of higher-level abstractions/components for xinful widgets/containers, maybe CSS-like styles.

2) Isn't this cross-runtime thing going to be compatibility hell?

Frankly- yes. The idea is that xinf developers will go through that valley of tears once and abstract the differences away so that you won't have to. That includes both differences between the target runtimes, and between different web-browsers. As for differences in functionality (things that, eg, JavaScript? simply cannot do), they will come in xinfony modules making it very clear that if you use those modules, you will give up cross-runtimeness. Which doesn't mean xinf is not useful there, too. On the long run, the xinfinity player will provide a feature set that equals or exceeds that of the Flash player, and thus provide a viable, open alternative without engaging into proprietary format issues or the like, and still making use of the broad distribution of the Flash player. Compatibility and rendering equality between the different runtimes will be assured with rigorous automated tests.

3) What license will the xinf components be published under?

Xinf can only be a success if it is as open as possible. As such, the core 'xinfony' API and implementation will be dual-licensed under the GNU Lesser General Public License (LGPL) *and* the common three-clause BSD license. Copyright will stay with the respective developers, but you are allowed to use, copy and extend it in any way you wish, for whatever purpose you have in mind. In somewhat of a GPL spirit, you are *asked* to publish/re-contribute any development you do for, in and with xinfony under some open license, but you will not be required to do so.

The 'xinfinity' player will be single-licensed under the LGPL, meaning that you still can use it in (even bundle it with) any project you like (open or not), but any modifications you make to the player code will be required to be re-published under the LGPL. As far as I can see, this will allow xinfinity to make use of (and be bundled with) other LGPL'd libraries, something it cannot do if it was to be published under the BSD license. (Any lawyer around to confirm or deny this?)

Note: it's not yet completely decided here. Is the dual licensing really neccessary, or would the BSD license be enough? Any comments appreciated. Meanwhile, the current xinf code is under LGPL.

4) Who is doing xinf? How can I help?

As mentioned above, xinf is currently a single-person project run by Daniel Turing (http://danielturing.com/). You are invited to help. Considering the current state of xinf, developers with experience in any of Flash, JavaScript? and C/C++ (and, obviously, haxe) are most needed, especially for review and contribution to the core xinfony API, and construction of a widget set on top of it. If you think you can help, please write to dan-AT-xinf.org and mention your experiences and what area of xinf you want to help with.

Apart from 'hard' development- xinf will need help with documentation and evangelism. It might not yet be the time to hit the bell big time, but if you are interested- please follow xinf development, contribute your ideas and ask questions.

As a third area, I am personally quite open to corporate (or private) sponsorship. Financial contributions will help me (and possibly other xinf developers to be) to stay focussed on xinf and not be distracted by day-jobs. Currently, my spare time is quite extensive, but money is known to be quite elusive. I still maintain a student lifestyle, which means i don't need much. Continuity is the keyword here. Of course, you will be rewarded with fame and glory and display of your logo in the respective sections of the xinf website.

For the time being, although easily influencable, I will stay the self-appointed dictator of xinf. If xinf catches on, I should be replaced by a proper democratically-organized foundation or something. Anyway, xinf is open-source (see 3), so I cannot do any stupid thing like suddenly require you to pay for it (at least, for what's already published).

The first step, if you want to help (or are even "just" interested), is to join the Mailing List, or browse the current Source Code