what about using swig to write client protocol? we just need to select
what language and compile.. no time spend creating one interface for
each language
KevinImNotSpacey escreveu:
This client looks really good for .NET. For instance the open source
client listed on danga doesn't fail very well when you pull the
connection on one of the servers in the pool, you get a flood of
exceptions. This client much more correctly flags the server as down,
removes it from the list and then checks to see if its back up at a
later time.
That alone is really sweet. Using native .NET configs is nice too,
the class design is also much more extensible. Everyone will have to
customize the client for their environment and this client will be
easy customize.
I would like to add the ability to define different "bins" or groups
of servers for different cache purposes, instead of having the one big
list, we can discuss offline. The only other thing i see right off is
that I'll need to remove the log4net debug calls for our prod
environment, but that's not a big deal.
Thank you very much for sharing this code, hopefully we can help
contribute back, I'll be setting it up and testing this week and next.
Thanks!
Kevin
On 7/6/07, *a.* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
we could argue which is more complete. my personal opinion is that
ported code usually doesn't take advantage of the target platform,
but mirrors an implementation which was tailored for the source
platform.
even if .net and java are similar, a code written for java can under/
over perform on .net.
additionally i did not feel comfortable with the architecture of the
ported code, mainly with the locking and server pool handling.
the description page on code plex is not finished yet (my bad), so
let me list the main features of my client
- it's configurable thru app/web.config, no more 10-20 line init
codes for the client
- written specially for .net, not ported, using the latest features
of the framework
- better (hopefully) locking providing better throughput
- uses consistent hashing for keys (based on ketama, found on the
list some months before)
- keys are hashed using FNV hash, much faster than md5 and have
better dispersion than the Object.GetHashCode()
- operations are factored into separate classes, so they are more
separated from the main client class, easier manageability and thread
safety
- more clients -> more options -> more competition -> better clients
a.
On Jul 6, 2007, at 1:29 PM, Antonello Provenzano wrote:
> Thank you for the support, but honestly I don't see the
advantage of
> using your library rather than Memcached.NET
> (https://sourceforge.net/projects/memcacheddotnet/), that is more
> complete and based on the Java client.
>
> Cheers.
> Antonello
>
>
> On 7/6/07, a. <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>> hello list,
>>
>> Previously I mentioned I had to create a client for one of my
>> projects from scratch.
>>
>> I'd like to announce that I've released it under a BSD like license
>> at http://www.codeplex.com/EnyimMemcached
<http://www.codeplex.com/EnyimMemcached>
>>
>> The state of the project is "works for me", but there can be
bugs in
>> it, so do not roll out in production before trying it out ;]
>>
>> If you have questions or comments feel free to comment me
directly,
>> or ask on the list if your question might concern others.
>>
>>
>>
>>
>> a.
>>
>> --
>> enyim.com <http://enyim.com>
>>
>>
>>
>>
------------------------------------------------------------------------
Esta mensagem foi verificada pelo E-mail Protegido Terra
<http://mail.terra.com.br/>.
Scan engine: McAfee VirusScan / Atualizado em 06/07/2007 / Versão:
5.1.00/5069
Proteja o seu e-mail Terra: http://mail.terra.com.br/
