Le 24/02/2010 14:37, Alexander Wagner a écrit : > >> 2. Should we ask TWIC again? >> > IMHO not needed at all. But I don't see why Mark would > refuse. > >
Some web sites are commercial, and I think it is fair to ask before using them in an automated manner (for example hooking http://www.shredderchess.com/online-chess/online-databases/endgame-database.html was not allowed). >> 3. If we had an ok, would it be tough to implement? >> > It is actually trivial. > > There is already some scripts around for that. But integration in Scid is certainly better for the user. The question is : how long will the service last without teaking a bit the code and/or URLs ? I never tried with chessDB (indeed, dead project now), but I was reported that this did not work and nobody was fixing it... But if TWIC's setup seems stable, then maybe it is time to plug it into Scid ? > BUT: there is currently no defined interface for these > things. Therefore you'll have to do a specific script for > each site you want to consider. And you'd have to either > invent a pretty complex parser that allows the user to > specify how to handle the site or you have to hardcode > things in Scid. The latter is considered broken by design. > Especially if you don't talk about persistent sites. > > Just to name a view points: TWIC used some internal path in > the ZIP files for some time while it was skipped later on, > reintroduced and seems to have gone again, now. All file > names are given in sequence and called twic<number>g.zip > containing the PGN. Trivial to do, but... > > The structure of ChessCafe is quite different. The file is > always called Default.zip and covers some undefined time > frame. The ZIP again contains a pgn file to unpack and load > into Scid. > > From ICCF Webchess on the other hand you get a single PGN > for each game. > > Conclusion: there're far to many different ways to handle > PGN donwload to have a general interface PLUS you have no > way to tell if any of the things you do today will work > tomorrow. So keeping things up to date is considered > troublesome. > > IMHO it would even be better to set up a webservice > somewhere that collects the games from the various sites and > offers them for download via some webservice/soap-calls. > Then we could add a simple inferface to Scid that allows to > select certain collections that get fetched to the local > database. Something similar to RSS for chess games. > > I agree. This would be really useful. But this is another project ... > Another option would be to have such fetch scripts done in > some sort of plugin architecture. But that approach didn't > get to much positive response when I suggested it way back. > > Plugins add trouble. My reasoning is simple : if a plugin is really useful, why isn't in the core code ? What is the difference between a broken plugin and a broken feature in the core (Tcl plugins should be loaded the same way other code is) ? Howto handle i18n with plugins ? etc. Pascal ------------------------------------------------------------------------------ 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
