Amfphp vs WebOrb PHP

For those of you who missed the great discussion over on Flex Coders.

Amfphp

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, Seagull)
• 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

WebOrb PHP

Thanks Patrick, I'm happy to talk about the goals we have for WebORB.The vision for the product is to provide the best possibledesign/runtime platform for Flex applications and .NET/PHP/Rubybackends. Our goals include:

• - non-intrusive approach
• - ease-of-use
• - simplicity of integration
• - extensibility
• - increased developer productivity

plus all the usual suspects expected anywhere from a one person shopto a major enterprise:

• - performance
• - reliability
• - scalability

Currently we're wrapping up a new release for WebORB for .NET and assoon as it is out in production, we will port all the new features toPHP and Ruby. That said, it means all the features one would find inour .NET edition are going to be available in WebORB for PHP (andRuby). For example, take a look at WebORB Data Management for Flex(http://www.themidnightcoders.com/weborb/dotnet/wdmf-faq.shtm), thisis something Flex/PHP developers would love to have. On top of thisadd real-time messaging, remote shared object support, data push, codegenerator, performance monitor, etc.

I highly value code clarity and elegant software design and I amstrongly convinced that a product with a clear and well-thought outdesign does NOT have to suffer in the area of performance. All ourproducts share the same design. As a result, porting features orfixing bugs takes only a fraction of time than creating a newimplementation from scratch. For instance, it took us only three weeksto create the very first release of WebORB for PHP.

And lastly, when choosing an open-source product (and this is strictlymy personal opinion) I would recommend going for one backed by acommercial entity. After all, if I bet my business on it, I want tomake sure I have someone to call at 3am in the morning if things go bad.

Cheers,

Mark