Hi all, I saw Pete's post about "the evils of event-driven programming in CLD clients." I tend to agree with him that the current API can be frustrating to think about. I had a few thoughts about what might be a better API: 1) when starting the cld session, the user code could register a "vtable" containing a bunch of different callbacks. That way all GET responses for the session could flow through my_get_response(), and so on. This at least would give the API user a single place to look when trying to find out how some CLD event is handled. Right now, we have callbacks installing other callbacks, which makes things hard to follow, IMHO. 2) provide a blocking API that users could take advantage of. I think for a lot of simple programs, programmers would be happy to spawn a thread per CLD session. In fact, I'm not aware of any programs that want to spawn a lot of cld sessions (maybe someone can point out one.) Most of the CLD uses that I've seen have been things like "find out who the master node is." For that kind of use, it seems unlikely that you would open too many sessions. In an era of multi-core processors and NPTL, spawning a dedicated thread to find the master is kind of a big yawn. I think a non-blocking API, in some form, should probably be available, though, in case people need it. We may not be able to anticipate all the uses that CLD is put to. Anyway... those are just my thoughts right now... Colin -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
