Monday, July 11, 2005
Someone, whilst looking over the diagrams in a previous post, asked me why the SWFContext package depended on the SWFIO package. The answer to that initial question is because the SWFContext package will (or has the high potential to) handle SWF tags, structures and/or primitives. I think it would be highly unlikely that, throughout the entire package, not one class or sub-package would handle objects from SWFIO. Handling (sans a higher-layer abstraction or wrapper) is enough to cause dependency.
The path that our discussion took, however, went towards "ActionScript only" coding, and how it wouldn't make sense to have just tags for keeping context in that case. This is entirely true: in a file where you have only two tags (an ActionScript and an End), the vast majority of the work is not going to be done with tags; it'll be done in the ActionScript VM, using context-saving methods that are designed for that purpose. However, note that there is no conflict here: SWFContext is a package, not a class. I used packages on purpose, because I really don't know enough about how the system should work overall (yet) to create classes.
Now, I surely haven't thought deeply about AS and how to design its implementation yet — and I most certainly didn't think about the situation of a completely programmatic SWF. However, the design does allow for these "future requirements" by creating appropriate extensibility points. To implement AS, we shouldn't need to change anything in the SWFContext package at all, nor should we have to change anything in the TagLogic package (aside from implementing the AS tag handler). Creating things inside of AS will be managed by the AS VM; the context will be allocated by that VM, and could then be stored in a variety of places (such as a void* in an STL map container, either in the TagData object itself, or back in some context object in SWFContext).
Now keep in mind that I made up most of the last paragraph you just read (that is, I hadn't planned it out in advance). The design is far from being coherent, let alone complete — it's just a rough roadmap for the time being. In fact, a very important detail (having a SWF- and/or tag-central location where multiple "plugins" can store independent contexts) came out of the exercise. I'm nowhere near touching AS, or rendering, or user input, or sound, or A/V sync, or any other of a million other broad and nuanced areas that the final player will encompass. That's why getting questioned and challenged along the way is ultimately a good thing — other folks can see the potential mistakes I'm making, and that gives me the chance to plan out and ensure I don't make that mistake. That is, after all, what design is about ;).
Note: I have been told by someone who recently downloaded the SWF specification that Macromedia has added a restrictive license to the end of the document. Because of this, newcomers will not be able to get a copy of the spec and still be able to contribute to GPLFlash's development. Since other developers (such as myself) already have access to the specification without the license, this should not pose a major problem in the short term. Please bear with us, and do not seek out or use this specification in conjunction with the GPLFlash project.