thanks for the replies. for now I'll play with the "easy" php version... hoping to get so big so fast to need the very-large-scale java version :) regarding to the "pick the one that suits you best" question, some sort of "mod_opensocial" apache module would be great (..it would be fun to code..)
thanks leo On Fri, Jun 20, 2008 at 12:33 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 3:17 PM, Leonardo <[EMAIL PROTECTED]> wrote: > >> Hi all, >> as far as I'm reading, >> it seems the java version is "better" from a production-ready perspective. >> am I wrong? > > > Yes, you're wrong :). What's better is really a matter of what your current > architecture looks like. If you're already a PHP (or anything CGI-like) > based setup, the PHP solution is probably better. If you're using Java, go > with the Java version. There are some different performance characteristics > of each, but those are language differences more than anything else. > > >> is it only due to the Caja availabilty? > > > Caja is really a non-starter at this point. Nobody's using it because it > isn't ready yet; when it is ready, it'll definitely be an advantage of a > java-based deployment, but PHP implementations can always leverage caja by > using a web service of some sort. > > >> are there other considerations? (i.e. scalability?) > > > Sure, but these are the same considerations for any "app server" vs. "cgi" > setup. The java implementation can handle more simultaneous requests than > the PHP setup running under apache (due to memory limits), but it also has a > much higher baseline memory overhead (due to the JVM). Deploying the PHP > setup is a lot easier than deploying the java implementation, but you have > more options on how you can deploy the java build due to the wide variety of > servlet containers out there. > > >> >> what about other implementations? >> a full-compliant RoR flavour would be great. >> >> Thanks to all >> leonardo >> >