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
>>
>

Reply via email to