If you are a Flex developer, I am sure that you know what SWC is. SWC files are component archive files (a.k.a. libraries) and it’s the library format of choice for Flash Authoring and Flex. SWCs are zip-compatible - that means you can use any zip utilities to open and view it.
The SWC format was co-developed by Flash Authoring and Flex several years ago - right around the period when the Flex project started. In a typical SWC, you can find the following files:
- library.swf
- catalog.xml
- some PNG images
library.swf contains component bytecodes and assets in the SWF file format. This allows the compilers in Flash Authoring and Flex to pull the bytecodes out of the SWC and insert it as-is into the target SWF. Flash Authoring can also use library.swf in the ‘preview’ section.
catalog.xml describes the list of components and classes and in the SWC file and also states the dependencies of the classes in the file. The dependency information in catalog.xml is important for the compiler and linker because they provide information to the compiler what classes to pull out and to the linker how the classes to be lined up in the target SWF. Some may ask why need catalog.xml when library.swf has the classes? Well, the classes are stored in library.swf linearly, not in a dependency graph format. That’s why library.swf won’t help the linker much.
SWC files may also contains asset files. For example, PNG images can be placed in a SWC so that Flash Authoring can use the PNG images in the component panel. Fast forward to the Flex 3 SDK release, you can see that we expand the concept of asset files to CSS files and resource bundles (.properties files).
Now, let’s take a step back and look at SWC again. The general idea of SWCs is that they are replacements of source files for tools when source files are not available. It is a compact, binary or semi-binary format. But as of its current form, it is ‘compact’ because it does not hold all of the information that you would normally find from source files. In other words, SWC does not retain enough information for tooling.
If you were about to build a tool that would support both source files and SWCs, you would need two separate codepaths for all the features in your tool. If you follow this line of thinking, you can easily see what are missing in SWC. I can list a couple here:
- character offsets for all the method signatures (e.g. method name, input parameter name and type, return type) and variable definitions in a source file.
- API comments
There may be more than that for tooling. Please speak out if you see more tooling use cases. I know the above two because I saw them first-hand in FB and asdoc.
My understanding is that compc knows everything but it does not split out everything it knows into the SWC, so my $0.02 is that they are not hard to solve.
Clement,
Thank you very much for posting your comments about compiler design and implementation.
I have been playing with compiler for about a month now and am really at loss on how to extend compiler in civilized way. I looked at the samples in documentations and sites like “code coverage” by Joe Berkovitz but it is really bad way as it requires OS contributors to add their features on the core level - and that is slow, Adobe-centric approach.
I am looking to extend MXMLC compiler using custom code generators, metatags and custom grammar extensions. As I follow the code I see that current product has no capability to extend current compilers - everything is very closely binded, with no integration points to just add any of these components ( hope I am wrong).
I am following up by adding custom mime type and overriding MXMLC compiler, but it places unnecessary strain on the coding model by forcing developers to wrap pieces of code as components. Hope to hear from you that I indeed missed something really obvious.
Sincerely
Anatole Tartakovsky
Very interesting posts. Keep up the good work!
-Darrell