New Java+PHP user

Brad Fitzpatrick brad@danga.com
Tue, 21 Oct 2003 17:35:02 -0700 (PDT)


Not sick at all... but definitely cool.

As long as you're careful about what you're putting in.  You can't, say,
deserialize a Java object in PHP, or vice-versa.  (Now *that* would be
sick.)

And yeah, the first layer of hashing (from key to server) is on the
clients.  Perhaps we should standardize the hash that all the clients use,
so cross-language stuff works reliably?

Or better, provide an option:  "standard_hash" or something, be that what
the Perl module uses, or crc32, or the Perl hash.  So modules can either
support the standard_hash option or not... they could use their own that's
faster (built into the language, or written in C), and only use the slower
standard hash if requested.

Client authors:  let's figure this out.  What hashing algorithms work for
everybody?



On Wed, 22 Oct 2003, Richard Jones wrote:

> Hi all,
> it's high time i joined this list :)
>
> We're using memcached for www.last.fm to store PHP objects.
> We are also using it in our Java streaming server for a few things, so i'm
> hoping to be able to help test/debug the Java (and PHP) clients
>
> Recently we have been setting info in memcached from our java streaming
>  server so that it can be read out using PHP. This allows the website to see
>  which users are connected, and what they are streaming. We used to do this
>  in a database - which involved a db hit every page load to check if a user
>  is streaming.
>
> i noticed that keys are examined to decide which of the available memcached
> servers to use to store them - i may be wrong, but i think that the java and
> PHP clients sometimes come to different decisions on which server to use
> given the same key. Anyone noticed this sort of behaviour?
>
> I guess using memcached to pass data from a java app to a php website is a
> rather perverted thing to want to do, anyhow if i find the problem i'll post
> a solution :)
>
> Regards,
> Richard
>
>
>