Thank for your reply Patrick! Now we are waiting for Mark Piller reply's. :o)
Good luck in your new job! David www.ideeclic.com --- In [email protected], "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<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 >
