I think framing and binary protocol should go together. The primary advantage of the text protocol (in my mind) is telnet, and framing makes that awkward.
As an alternative to flags, we could just let the server interject certain extra responses before each regular response. If a client receives such an interjection, it can deal with it and then try to read the normal response. As another alternative, we could have client-generated command tags and allow the server to send responses out of order. Sort of like 9P or IMAP. That would make extra server responses trivial to support. This strategy has at least one other advantage, too, but, like framing, it makes telnet interaction awkward. It also practically forces clients to be asynchronous. (BTW, as a Plan 9 fan, some day I'd like to see a 9P server that proxies to beanstalkd.) On Sun, Jan 11, 2009 at 12:55 PM, Dustin <[email protected]> wrote: > I'd expect [message batching] to work anyway. I did it with my > memcached client and it worked flawlessly. It *did* expose bugs > that were introduced to the server later on, though. Beanstalkd is explicitly designed to support this. Should protocol.txt be more clear? I'd welcome suggestions for wording. kr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
