On Jan 29, 2008, at 13:21, Ciaran wrote:
There is at least one common hash algorithm I think every client
supports.
I guess this is the FNV hash? For my purposes I hash the key outside
of memcached to avoid this particular issue :)
No, there's a CRC32 based hash that I think everyone supports.
The hash I'm referring to is the one used to locate a node.
There are two node location algorithms many clients support -- at
least one they all do (should?)
I'm not even looking at clients that don't support the 'consistent
hashing algorithm' ;)
I've seen three of them discussed for use with memcached.
Someone put together a matrix of flag usage recently. It seems
there are commonalities, but mostly by coincidence. This needs work.
I believe you probably mean http://www.hjp.at/zettel/m/memcached_flags.rxml
.
Yes, that looks right.
I've also compiled my own one looking primarily at the content
encoding types (currently sitting in an open-office sheet on my work
pc, which I'm hoping won't have locked up overnight!), comparing all
the C# + Java clients (stupidly I also tried to work out what
libmemcached did before realising how meaningless the question
was!) I'm more than happy to splurge out this information if it is
of interest to other people :)
Knowing where we are is definitely helpful if you can provide more
information. We still have to agree to move towards a specific
direction, though.
Content encoding varies greatly. Strings are somewhat easy, though
not universal, but there are other common types that could handle a
common encoding.
One that I came up against was Unsigned vs Signed i.e. some
platforms don't support types at all that other platforms do <g> I
can see why its a decision that has never been cleared up / agreed
upon :) You'd think that once a content encoding mechanism had been
agreed it would be trivial to add in a 'cross-platform' encoding
mode to clients on an adhoc basis, but I suspect my view of things
is skewed/simplistic :)
That's true, but there are a few things that are common that can be
covered:
* Strings
* Dates
* Lists
* Dictionaries
* Fixed-precision numbers
* Floating-precision numbers
* Booleans
* Blobs
Things people decide are common can be standardized. Either way,
there will need to be room for things that can't be considered common.
Take care
- Ciaran
--
Dustin Sallings (mobile)
On Jan 29, 2008, at 12:58, Ciaran <[EMAIL PROTECTED]> wrote:
>
> There is some flag space reserved for something like flags
that
> aren't supposed to be exposed in the client APIs, but I'm having
> trouble seeing the point. I'm under the impression that not a lot
of
> users make heavy use of the flags for anything other than content
> encoding. That is, at least, where all the confusion is.
>
> Thats a shame, perhaps I'm an edge case, do most people not share
> across platforms, or if they do just store 'raw' data ?
> - Ciaran
--
- Ciaran
--
Dustin Sallings
