[xinf] xinformal: onto iteration 3!

[Daniel Fischer]

dear all,

now it's really been a year. For some reason, i manage to remember june 6, 2006 as the date i publicized the xinf idea (from a small town in bosnia), at that time as a very early and rough draft, really.

things have changed. xinf has (to my knowledge) no users except myself, but i'm in fact using it intensely. i'm mainly using the xinfinity "native" "opengl-accellerated" runtime-- flash and js implementations haven't really changed for surely half a year. they "should work".

please dont mistake the lack of SVN commits as a fatal symptom- xinf's in fact rather stabilizing than dying :)

obviously, i'm running on my own agenda here and there might well be bugs and other critters in the current implementation. in fact i'm sure there are-- i havent managed to fix the bug(s) causing xinfinity to fail on zjnue's windows machine- while i managed to segfault 'nicely' on some windows thing once, i now cannot reproduce any problems here. this fact is indeed blocking me from calling the current state xinf 0.1.

maybe i should rethink my versioning strategy. it seems too conservative sometimes.


so, to the matter: my plans for a third "iteration" (i.e. major redesign) are clearing up. i plan on a somewhat smooth and easy transition there, as i'm (as hinted) using this stuff already in a project that is very important to me. i think i have found a path that will allow me to shift around some foundations while still using the "old" implementation in a transitory phase until all target runtimes are implemented.

let me first state some observations about "current" xinf, aka "iteration 2". I'm unsure if anyone understands the design at all (lack of docs surely doesnt help), so here's a fresh rundown of the whole idea (using Captials for the keywords):

 remember xinfOny, xinfErno and xinfInity.

Xinfony, aka "Ony", was and will be (and is currently only slightly) supposed to be the "primary entry point" when using xinf. A simple DisplayObject model: create a Rectangle, set its Geometry and Style, attach it to some parent. Xinf will take care of the details of causing some rendering engine/runtime to display it. You can register for mouse Events on this object, and for keyboard events on some global object.
Apart from Rectangle, there are classes like Text, Shape, Image or Group. Ony is the "fruit" of xinf, the primary API. You should not have to care about the details.

Those details being abstracted in xinfErno. Erno implements the idea of an "immediate rendering protocol", similar to opengl or openvg, a chain of Instructions for drawing and managing display objects. It is currently incarnated as the xinf.erno.Renderer interface[1]. I've described my "original" idea for such a protocol in [2].

So in the current model, Erno is the abstraction layer- there are three implementations of xinferno "renderers" (and associated "runtimes"): one for Flash9, one for "JavaScript" (aka DHTML) and one, making up the majority of code in xinf svn, a cross-platform (linux/osx/win), opengl-based runtime environment: Xinfinity.

Inity, proportionately to the tasks at hand, is where most of my energy went (and probably will continue to go). A vector rendering interactive runtime is a bit of work :) I'll spare you the details for now, but maybe i should forget modesty for once and say that i'm rather proud of it. it surely has problems, but thanks to the help of a number of opensource libraries (standing on the shoulders of giants here), it can now do quite a few tricks and even manages to look good most of the time :) And i managed to cover some ground of packaging the whole shebang into a haxelib. remember "haxelib install xinf".


these are the basics of xinf. apart from xinfinity, quite some work went into the construction of a basic widget set (XinfUl). It's "completeness", while surely imperfect, would probably surprise you if you had a look at [3]. There's some more even, though it probably all needs a cleanup. I should note that these widgets are backed by pretty elaborate "styling", which also plays a role in some until-now-undisclosed "experimental xinf modules" called xml and svg [4.1 and 4.2].

i am noting these developments to you because the current SVG module, as naive as it is, is proving invaluable in my current developments. so much so that i have decided to make it the basic of iteration 3.


So here comes the idea for the future (drumroll): Ony will become, once more (as in iteration 1), the abstraction layer. But it will in fact try to implement SVG, at least the basics of it (scripting support will obviously be haxe-based).

As i still have belief in the "rendering protocol" idea (xinferno), and because i already have implementations of it, i will use it to initially flesh out xinf.ony (it currently is a relatively small and sad module really) towards what i imagine. The "approaching CSS" Style module will move from being experimental to being fundamental to Ony. There might be some other basic idea which i cannot describe yet, also enabling Ony. 

Obviously, "the new Ony" will be designed so it can later be "optimized", i.e., there can be runtime-specific implementations of Ony instead of the current detour via Erno. The rationale being that an object model fits flash and js (and probably alternative C-based renderers) actually much better than the protocol model.

I will likely to continue using xinferno even after flash and js (js probably requiring an SVG-capable browser then) are "ported", for xinfinity. There can and might be "object-model-based C renderers", but i will -as said, definitely first and likely also later- maintain xinfinty as a xinferno-based implementation of xinfony. all clear? read that sentence again :) 

in other words: you (if you want) will write against the (simple, SVG-like) xinfony API. there will initially just be one Ony implementation, based on the current xinferno-- thus, already being
cross-runtime. later, there will be "direct" xinfony implementations for flash9 and (at least) firefox, optimizing those platforms. the then-old Erno implementations will be dropped. the initial Erno-based Ony implementation will continue to exist- as "Xinfinity".


The aim of all this is a "lean-up", in hope to provide a really valuable haXe-based toolkit for cross-runtime vector graphics with a nicely graspable core API with a strong SVG bias. There is some core paradigm shift involved (from inheritance to composition), but i doubt anyone except Mark will really take note of this :)

questions and comments are, as ever, very appreciated.

-dan



[1] http://xinf.org/trac/browser/trunk/xinf/erno/Renderer.hx
[2] http://iterative.org/strive/
[3] http://xinf.org/misc/test-070608/TEST.html , but note that it will
a) only work in a recent Firefox and b) is currently completely broken
on flash
[4.1] http://xinf.org/trac/browser/trunk/exp/xinf/xml
[4.2] http://xinf.org/trac/browser/trunk/exp/xinf/svg