Keep in mind that AMFPHP may go under the radar (or drop off it
completely) as the lead developer has decided to pursue another career and I have not seen any announcement of anybody else taking over for him.
I'll be releasing amfphp 2 before I retire, and I have someone here that is interested in picking up amfphp, someone I can't mention just yet but trust me that my successor will be a very talented and respected member of the community that I am sure will do an awesome job with the project. As to which you should choose between amfphp and WebORB, it depends. Mark loves his WebORB, and I love amfphp, but they are different projects, and have different design goals, so that either one is most appropriate for different uses. The differences are subtle though, I'll be the first to admit, which is why I wasn't particularly thrilled about WebORB and SabreAmf when they first came out, as I felt it was a duplication of efforts (much like the well-publicized argument over SWX with Aral). But regardless, the effort has already been put in, so there's no use in stopping it now. I'll restate the design goals of amfphp from the homepage: - Nothing required - PHP4/PHP5 compatible, no extensions needed - Low footprint, lightweight, fast - Convention over configuration (service and class mapping) - Can be embedded into a framework (see CakeAmfphp<http://cakeforge.org/projects/cakeamfphp/>, Seagull <http://trac.seagullproject.org/ticket/1378>) - Services are "non-specific" PHP classes that are portable to anything without code change - Productivity tools included (service browser, code gen, profiling) - Batteries included - XML-RPC, JSON - Not a framework by itself (use your own) I'd like if Mark could put up a similar statement of design goals for weborb so that users can make an informed decision. As for the issue of the AMF extension, I've contacted Mark about it, and in theory weborb could be made compatible, and SabreAMF will be eventually (as far as I can tell). I don't think Mark wants to do it though, perhaps because of the way the serializer is implemented on their side. My personal feeling is that the serializer and unserializer in WebORB are misadapted to the realities of PHP, split into several classes for doing simple, computationally intensive things, but one could argue (and I'm sure that Mark would) that clarity of code was chosen over performance, a valid decision if it doesn't affect performance that much (and Mark is right, the 50-200ms difference won't really make a difference in most projects, but in some which have very high traffic it most definitely will, which is why the AMF extension was made). Patrick
