> What Jarrad is referring to here -i think- is that i mentioned to him that
> swfmill will be reimplemented in pure haXe. it's a bit far up my sleeve tho,
> meaning, it's a while to go.
Oops sorry looks like I skipped that point !
> i'm not so sure that ming is not up to date- AFAIK, it supports all flash8
> features (not sure), something that swfmill is not up to (just yet- although
> steve is working hard on it). Also, swfmill in its current form is not well
> fit to do bindings- it *could* be done, but would be a mess.
If you need some infos about some of the new FP8 stuff I've been doing
some work on it for the MTASC/haXe SWF library.
> i'm still unsure how to re-do swfmill, the only sure thing is that i will
> (someday). a pure C "libswf" for reading/writing would sure be nice, but i
> also like haxe so much that i maybe wont care. obviously, though, a libswf
> could nicely be bound to neko to construct the actual swfmill functionality
> (xml conversion, font/image import) in haXe then.
>
> also, ming has the advantage of being known to a lot of people- PHP
> programmers, eg, so maybe a ming binding would make sense after all.
Yes, true.
In my thinking it was a not so much up-to-date but maybe I should have a
look at it again.
> meanwhile, of course, swfmill might well be used as an external tool- just
> feed some swfml-simple XML into its stdin, and it will give you an SWF on
> stdout ("swfmill simple stdin stdout")
Yes that's very useful already.
For the Web it doesn't make a lot of sense to be able to dynamicly
generate SWF, unless for captchas maybe :)
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
