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.
The Arp Questionnaire Results and Statistics article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
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.
The Arp Questionnaire Results and Statistics article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
hey, no, thank YOU for the time you put in developing ARP. It’s great to see you soliciting feedback like that to try and improve the product…can’t wait for ARP 3.
Wierd to see SEPY so far down on the list though…
Hey Rich,
Yeah — I use Sepy alongside Eclipse. I find I use the two in different ways. Nothing beats Sepy for the quick edit ;) As I mentioned, it’s a small sample!
No one’s using FDT?
From this and the post on AMFPHP 1.2 it looks like AMFPHP and ARP are getting it on. As a PHP hack this makes me want to take another look at ARP.
I’d be interested to hear how people get started with the framework. Personally I found it a bit overwelming.
tonio – well, for me, i delibrately studied patterns first before gettinng started with ARP…that helped tremendously, allowing me to fully understand what was going on in the framework.
Also, pretty much immediately when I was getting started with ARP, I found the extensions mentioned above, which really hooked me in as far as using ARP…some of the things that were maybe a little bit confusing about developing in ARP were cleared up by using them.
flashape – Thanks
I’m not a complete novice. I built a big RIA on PHPObject last year and I’m working with MTASC, FDT, ASDT, AMFPHP, Ant et al now.
There are a _lot_ of pieces to the OSFlash puzzle but I have them all in place and am happy to not need the Flash IDE for anything but the odd timeline animation from here on in.
ARP on the other hand… For someone like myself it’s a catch 22, unless you’re comfortable enough with the patterns to have written a framework then it doesn’t gel, at least not yet.
I guess I’ll come back to this after I’ve fully digested Design Patterns Explained.
Hey Tonio,
Also take a look at Head First Design Patterns from O’Reilly. A very accessible book.
And yeah, Arp and Amfphp are getting it on big time. If this keeps up, we’re going to have to ask you guys to look away — or get a room — or something! :P (Damn, if it wasn’t first thing in the morning I could blame it being past my bedtime!) :)
For the record, I’ve used both FDT and ASDT on different projects. At the moment, though, I’m digging Flex 2 and Flex Builder (although the editor is not as sophisticated as FDT’s yet.) :)
i also recommend Head First Design Patterns. Easily one of the best programming related books I have read. I havent read Design Patterns Explained, but HFDP uses a different approach altogether to “load patterns into your brain” (what they say in the book).
Good to know about the amfphp stats. I always thought that OpenAMF was more used with ARP. guess the battle’s already won then. In that ase, the new ARP base code generation features will certainly be put to good use by ARP users.
[...] AMFPHP provides a server-side data transport layer, which enables server process calls that return objects which are native to the Flash platform, no XML or other text based format deserialising needs to take place. The advantages should be obvious. http://www.amfphp.org/ – Homepage http://aralbalkan.com/529 – Comparison of OSS and Remoting options in use (AMFPHP outnumbers other options by 3:1) Red5 [...]
Hi every body,
Who knows why AMFPHP doesn’t work in IE7?
http://www.amfphp.org cann’t display home page in IE7!!!.
What’s wrong?
IE7 wrong or AMFPHP or Flash?
Yours sincerely
Jian Zhan
[...] AMFPHP AMFPHP provides a server-side data transport layer, which enables server process calls that return objects which are native to the Flash platform, no XML or other text based format deserialising needs to take place. The advantages should be obvious. http://www.amfphp.org/ – Homepage http://aralbalkan.com/529 – Comparison of OSS and Remoting options in use (AMFPHP outnumbers other options by […] [...]