From: John J L. <jj...@po...> - 2002-10-23 10:57:48
|
--On 22 October 2002 10:33 +0200 Frederic Gobry <go...@pu...> wrote: > Hi, > >> http://www.iro.umontreal.ca/~pinard/recodec/ >> >> ...and there was much rejoicing! > > Yep, I was just testing it yesterday evening with great pleasure. The > major drawback I can see is the need to rewrite the bibtex parser (as > it uses recode internally too), or parts of it. Maybe this is not a > bad thing if we want to expand it so that it supports advanced > features (like keeping style information). Then we could have a 100% > python pybliographer, which is also a good thing for portability. Absolutely! Actually, I wrote a post about this in which I wondered what the new i18n code that seems to have turned up in CVS is for (that post is sitting on a hard drive on a currently dead machine -- new parts arriving today, finally). Is this code really necessary? As you know, the two major portability issues are C code and GNOME-specific GTK code. I eventually got all the C code working without segfaults on Windows, but adding new C code is potentially painful for ports. Moving bibtex to pure Python would certainly be nice... On the other issue: has anybody tried porting any of the GUI code to Windows yet? I mean by just going through the code and doing a simplest-possible abstracting-out of the GNOME-dependent parts, rather than anything like anygui (which isn't far enough advanced) or pyblio-specific GUI abstraction (see below), or simple port to another toolkit (time-consuming to maintain). Is this even the right time to be doing this -- do you plan a complete step-change in the GUI code, or will it just be lots of relatively small changes? Personally, I am wary of going for any grand abstraction schemes (in terms of pyblio rather than GUI concepts, that is) whose primary intent is to make GUI porting easier, because it will probably become much clearer what is really needed after a simple-minded port has been done. If there is a clear need for abstraction for some other purpose, then of course that's another matter. Do you agree? I saw you've done quite a bit of work on queries in CVS -- haven't understood the code yet. > I hope that speed won't be an issue, as for large files a real > database backend will be available. Idle thought: have you considered ZODB? Jeremy Hylton said something about this when I mentioned in passing that Peter had referred to his thesis on this list. Kind of like pickle but with transactions and multiple 'Storages' -- flat file, Berkeley DB, relational (latter was experimental when I experimented with it a year or two ago). There are some minor restrictions on class interface and implementation, but it allows you to get rid of the mapping layer to/from relational DB. John |