On Sun, 2010-02-28 at 21:49 +0100, Alexander Wagner wrote: > Ben Hague wrote: > > Hi! > > >> I could do it, the only thing I don't know about is how to > >> handle ZIP in a simple transparent and portable way. I'd > >> tend to call the commandline unzip that is freely available, > >> but usually it's not there on a certain platform. > > > > Presumably it wouldn't be a big problem to include one of the freely > > redistributable unzip programs in the scid package for a certain > > platform, or possibly a VB Script? > > VB is windows only, and distribution unzip, well at some point we'll end > up with a ready to run Linux CD just to run Scid. The canonical tool > would just be unzip for ZIP, but people might think using other > compression tools.
Well, looking into it further it does appear that TCL 8.6 will include unzipping by default, if I understand http://wiki.tcl.tk/4610 correctly, so any external program would only be short-term. I was thinking of using unzip where it can be reasonably be expected to be found and adding one where it can't. There doesn't seem to be a nice way to do it. > >>> I agree. This would be really useful. But this is another > >>> project ... > >> Sure. I did not mean the Scid project to do it. But if there > >> is a willing and skilled web programer arround... > > > > I did wonder about that, but it looks like it would be a pain for > > whoever was responsible for keeping it up-to-date. > > I'm not sure about that. And it would have to be kept up to date only in > one location which has a charming aspect. Setting up a nice web > service/SOAP interface in front of it would avoid all trouble. Anyway, > this is not a short term solution. > > > Instead what about > > doing something similar, but with screen-scraping instructions rather > > than the actual files? > > ? > > > E.g. something like: > > <GameSource name="TWIC> > > <URL>"http://www.chess.co.uk/twic/twic";</URL> > > <Regex>"http:\/\/www\.chesscenter\.com\/twic\/zips\/twic\d+g > > \.zip"</Regex> > > <Type>ZIP</Type> > > </GameSource> > > If I get you correctly you suggest a simple xml file with the necessary > instructions to get the games and process them. This is what I had in mind. > > But, frankly, given the recent discussion about usabilty, which is > mainly about some bitmaps and fonts, I don't think we have a majority if > I tell the people that vi is a very nice gui for editing connector files > of the above kind and that it is very easy, just set up the correct > regexp. Especially, as Tcl seems a bit picky about escapes here as I > recently learned. (I'd want a solution that allows this, but does not > require it.) I wouldn't anticipate end-users ever coming into contact with this. I'd envisage one central file containing all the definitions and the end-user contacting a maintainer if they want a new site adding. You might want a local file as well for some special cases but I would imagine only a small minority of advanced users ever needing that. > Given we agree that we want such a fetch function, which I feel is the > case, your suggestion is the way I'll do it. I'd just supply the above > connector for a bunch of sites. I'm not sure about the usage of XML for > the connectors, however. (I think it would be good but it also rises > deps for Scid). But I'd suggest to supply the connector defs via Scid > probably add a fetch function which gets the file in question from the > Scid website if needs be. I would suggest XML because it gives more flexibility. I.e. if some other program wants to use it as well then it should be much easier if it's in a standardish format. Also, there's a chance of an XML parser being built into TCL which there isn't if we use our own format. Ben Hague ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
