Phil Dibowitz wrote: > Stephen Warren wrote: >> I really don't like the static buffer used by get_key_name. ... > > I went back and forth on this myself. I don't like it on principal, but > then again, libconcord also does this. > > They're not 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.
Oh, I guess looking at the implementation, get_key_name does check if data is different to the last call (but not size, which it really should check too), and reset the internal iterator state (XMLBuffer global variable) if it changed. Whilst that does allow client apps flexible use of the API, that actually makes me like the implementation even less... >> 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. At least in congruity, I will make the client application use get_key_name to retrieve a list of all known key names into a Python list, and then iterate back/forth within that. The advantage of this is that I can display the entire list up-front on a page saying roughly "this is what we'll do on the next pages, click next to start", and then have the wizard walk over that list. It's much more efficient in this case to parse the XML just once, and store the results, rather than parse the XML once to display the list on the intro page, and again whilst walking through the keys. >> 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. I'm not totally opposed to some verbose mechanism. I just don't want congruity to have to trigger it, and the implementation needs some work too. That said, even right now if any kind of problem occurs in libconcord.py, it'll throw an exception, and the full trace will be available to a user to include with a bug-report via the congruity details button on the failure page. ------------------------------------------------------------------------- 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
