Thanks Patrick, I'm happy to talk about the goals we have for WebORB. The vision for the product is to provide the best possible design/runtime platform for Flex applications and .NET/PHP/Ruby backends. 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 shop to a major enterprise: - performance - reliability - scalability Currently we're wrapping up a new release for WebORB for .NET and as soon as it is out in production, we will port all the new features to PHP and Ruby. That said, it means all the features one would find in our .NET edition are going to be available in WebORB for PHP (and Ruby). For example, take a look at WebORB Data Management for Flex (http://www.themidnightcoders.com/weborb/dotnet/wdmf-faq.shtm), this is something Flex/PHP developers would love to have. On top of this add real-time messaging, remote shared object support, data push, code generator, performance monitor, etc. I highly value code clarity and elegant software design and I am strongly convinced that a product with a clear and well-thought out design does NOT have to suffer in the area of performance. All our products share the same design. As a result, porting features or fixing bugs takes only a fraction of time than creating a new implementation from scratch. For instance, it took us only three weeks to create the very first release of WebORB for PHP. And lastly, when choosing an open-source product (and this is strictly my personal opinion) I would recommend going for one backed by a commercial entity. After all, if I bet my business on it, I want to make sure I have someone to call at 3am in the morning if things go bad. Cheers, Mark --- In flexcoders@yahoogroups.com, "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 >
