On Sun, Aug 19, 2012 at 5:51 PM, Carl Douglas
<address@hidden> wrote:
Thanks for reporting these bugs!
I am overseas on holiday at the moment and the soonest I will be able to take a look is next week after the 26.
Regardless, you are welcome to fix these yourself, and I would encourage it!
Sounds good. I am in fact working on it. The exception-in-transactions issue is easy; I've written code for that ... though strictly speaking it's additional functionality rather than a fix. I didn't see a straightforward way to prevent the connection from being hosed when the transaction is done as a series of discrete commands, i.e.
(redis-multi) (redis-*) ... (redis-exec)
so I wrote a macro called redis-transaction that runs an arbitrary series of commands, preceded by redis-multi and followed by redis-exec, all wrapped in an exception handler that, as I proposed, calls redis-discard and then re-raises the exception. It seems to work but has not been thoroughly tested (I guess this would be a good time for me to learn how to use Chicken's testing facilities ;-).
For the other stuff, I will have to find out exactly what data is being sent back and forth ... hmm, can I use Wireshark for that ... I'll give that a shot.
Also, I think the STRING-UPCASE call in your macro is unnecessary; although the canonical form of Redis commands is uppercase, it appears they are actually case-insensitive. I've asked about that on the Redis forum, and a couple of people have assured me that it is so by design.
The redis-client.scm code is minimal and does not specialise per redis command.
Well, sometimes minimalism is best.
Also you may like to consider an alternative redis implementation for chicken scheme, there is one hosted on gitorious.org somewhere I believe.
I don't know about that. Since Redis has a very simple interface, I don't see much reason to have different approaches. And since yours is already in the egg repo, I'd say making yours the best it can be is the way to go.
I am also developing some value-added functionality that is useful to me, and may or may not be useful to others. As of now, I'm putting that stuff in a separate egg called 'redis-extras' (which I plan to publish soon, but not just yet). It includes:
1) Database allocation -- so that you can have multiple apps using one Redis server without the risk of them
changing each other's data. Database #0 is used to track which databases are assigned to which apps;
each app registers with its app-name (a unique string) and is allocated a database according to that name.
2) Proxy objects -- e.g. a hash-proxy with an API analogous to SRFI-69 hash tables, but with built-in persistence via
Redis; and similar list- and set-proxies. Though actually, these would probably be most useful if they were built to
allow interchangeable persistence mechanisms, so maybe they don't really belong in this egg.
--
Matt Gushee