Arp Questionnaire Results and Statistics

At the start of January, I ran a questionnaire on the Arp mailing list to try and get a grasp of how developers are using Arp. Part of the questionnaire was aimed at understanding which other technologies Arp was being used alongside. To this end, I asked developers to provide information on which client side, server side and remoting technologies (if any) were used in their projects. All of this data is now sitting comfortably in an Excel sheet and here are some aggregate results.

Client-side technologies

The winner here is the Flash IDE. It was used in 17 out of 18 projects, usually alongside open source technologies. If anyone needs proof that open source tools like MTASC and Eclipse/ASDT compliment the Flash IDE, here it is! Eclipse and MTASC are also widely used and perhaps Ant use was underreported as I didn't specifically mention it in the question.

Server-side technologies

Any surprises that PHP comes out on top here? What's interesting is the CF looks to be second with J2EE and .Net trailing behind. This may be due to the low sample size in this study.

Remoting technologies

Mirroring the use of PHP, Amfphp comes out on top here by a large margin, with CF in second place. The use of Remoting in general mirrors the use of server-side technologies, which is to be expected. What is not reflected here is that several projects used client-side XML as their source of data.

Finally, 1 project used Flash Communication Server and 2 projects used JavaScript integration.

Alongside the quantitative data, respondents also provided feedback regarding extensions they've used, their loves and hates and top feature requests.

The thing most respondents love about Arp is the structure that it provides for projects; "knowing where all my code is" as multiple respondents stated. Hates? The coupling between commands and views for model updates is one (and this is remedied by the ModelLocator) and the effort involved in the initial project setup and the initial learning curve are other popular hates.

The most popular Arp extensions used were Grant's SystemController and CommandController classes from the arpx package, Christophe Herreman's arpx extensions, Jesse's extensions and the LSOService for Shared Objects.

A number of respondents stressed that CF remoting should be supported in future releases of Arp and, with Sam Shrefler's recent excellent work integrating Arp with Tartan and the vastly improved remoting implementation in Scorpio, I don't see any reason not to. For the record, Arp will support the following remoting technologies: Amfphp, openAMF, Fluorine and CF.

I want to thank everyone who took part in the Arp questionnaire for taking the time to respond in such great detail. Arp is going to be better for it. Specifically, thank you Gert-Jan van der Wel, Stefan Richter, Mike Britton, Jed Wood, Rich Rodecker, Grant M. Davis (who submitted six project reports), Folkert Hielema, Chris Velevitch, Paul Booth and Sam Shrefler. Also, thanks to Christophe Herreman and Darron Schall for your insightful comments on the questionnaire thread.

Based on the feedback I've received, I'm going to be drawing up a roadmap for future Arp releases. One thing I'm sure of is that there will be many small releases, not one giant release. So, Arp 3 is more of a goal to aim for rather than a destination. There will be quite a few point releases on Arp 2 before we reach there, based on the most common feature requests and consultations with the community.

There are also very exciting parallel developments with the next version of Amfphp, which will be generating Arp code.

There's a lot of work to be done in the coming days and it's all very exciting.

Remember that there are two things that make Arp unique and hugely useful: One, it is lightweight and simple and two, it aims to support the Flash Platform – not just a single Flash technology. To that end, it currently supports Flash/AS2 and Flex 1.5/AS2. Flex 2 and AS3 support are of the highest priority, as is MTASC. When I say support, I mean comprehensive documentation alongside merely compiling in a given technology. As we need to support these various technologies, keeping the core framework as simple as possible is of utmost importance. These considerations, alongside that of having a single, consistent sample application and minor updates to the framework, will form the bulk of the near-term releases.