Stephen Warren wrote: > I really don't like the static buffer used by get_key_name. It's nasty > that a client can only use this API on a single data blob at a time, and > that the API internally maintains non-obvious implicit state. I'd prefer > something more like the API below, where the XMLBuffer is dynamically > allocated per iterator, but the type/content is still opaque to the client:
I went back and forth on this myself. I don't like it on principal, but then again, libconcord also does this. They're note equivalent however... one involves working with more than one remote at a time, which is outside (at least the current) scope of LH. So the question is - do we want to support more than one file AT THE SAME TIME? Given the current API you can in fact go through more than one file at a time. So being pragmatic, it's not so bad. Thus I've gone back and forth a few times, and can't quite decide. > No reversing or random access allowed either; should be much simpler. So I guess the idea with this feature is being able to go "oh, damn, I hit the wrong button on the other remote and don't want to have to go back and redo the whole sequence." I like that. > encode_for_posting needs to define who owns the memory returned, and how > to destroy it. True - and as you point out - true for many other parts of the API... > I'm not convinced that the Python bindings changes for "verbose" are the > correct way to go; they don't handle exceptions very well. It'd be best > if you removed the "verbose" part from the Python bindings, and I'll > work on a more automated and robust solution, and one that doesn't > require the host application to configure it, since I don't really want > to include that kind of debug logic in the production version of congruity. I didn't read through those changes, but I would say that seems reasonable to be able to enable debug in a production version so you can tell your users to do this when they report some problem you can't reproduce. -- Phil Dibowitz [EMAIL PROTECTED] Open Source software and tech docs Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "Never write it in C if you can do it in 'awk'; Never do it in 'awk' if 'sed' can handle it; Never use 'sed' when 'tr' can do the job; Never invoke 'tr' when 'cat' is sufficient; Avoid using 'cat' whenever possible" -- Taylor's Laws of Programming
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
_______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
