'noreply' over the wire

Tomash Brechko tomash.brechko at gmail.com
Sun Nov 11 17:58:28 UTC 2007

On Sun, Nov 11, 2007 at 08:36:46 -0800, Steven Grimm wrote:
> >Your notion of real-world is limited to your own projects.  There are
> >applications where updates are no less frequent then queries.
> Such as? All I'm asking for is a real-world use case. I don't care if  
> it's one of my own projects or not; I just want it to be a real  
> project that actually exists.

This last mail is very sound and reasonable.  But your question is not
about whether there are projects that do lots of updates, sure there
are.  But first you actually suggest to solve all problems on the
client side, like rewrite Perl module to support streaming, rewrite it
to use Dustin's Java multiplexer (but I already wrote about at least
one problem with it).  Streaming in Perl module can indeed be done
without using threads, yes, but it will be quite a complex processing
on client side, so the resulting client+server may have a worse
performance.  And you advise me to do all that just because you don't
want to touch the server, even though you can't show my patches do
anything wrong.  And even with streaming, I don't see the reason for
the replies to be in the wire _at all_, for what it worth.  The other
questions you raised regarding robust error handling were already
answered in my first mail.

So if your question is whether there are projects that can't solve all
shortcomings on the client side, the answer is: dunno.  Yes, I can
implement streaming and deal with other problems on my side (by
forking, for instance).  No, this won't be the best solution.

But if your question is indeed whether there are projects that might
benefit from 'noreply', and you are ready to accept the patches if
there are, then I'd rather not reply to that.  I don't want any change
for _only my_ projects ;).

Hey, list, does anyone see the use for 'noreply' in his project?  Can
someone do some measurements?  Thanks in advance!

   Tomash Brechko

More information about the memcached mailing list