this ...Post is really awesome and very cleared for newbies like me .
Patrick Mineault <[EMAIL PROTECTED]> wrote: >
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, 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
---------------------------------
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
