2009/7/7, Alexander Wagner <a.wag...@physik.uni-wuerzburg.de>:
> Pascal Georges wrote:
>
> Hi!
>
>>> Pascal: the latter would be an example usecase for "per
>>> based defined user-flags". Just as you asked, there're more
>>> uses of that kind. (This does not yet refer to indexing
>>> them. But I can imagine a user flag u1-u16 and some field
>>> within the database where I may assing the text "problem
>>> solved" to u1 so Scid shows "problem solved" if u1 is set.)
>>
>> I understood this. My previous remarks are still valid. In
>> this example for "exercise solved" I'd better add an extra
>> tag [ExerciseSolved "1"] instead of re-using a standard
>> one. The use of extra bits in the index is not mandatory
>> here and certainly an over-kill.
>
> For this case yes, for others I'd really appreciate it. E.g.
> it would really be great if I had some flags to mark "I have
> this game in a book" more decently than !? flagging.
> Currently I've some games flagged bw!?... Some of my user
> flags would be "Ref available", "Opening", "Repertoir",
> "Own", "To study". I'd still use some of the standard ones,
> those flags are not too bad, indeed.
>
>> To be more precise, there are 3 scenarios :
>>
>> 1. Current user flag set to 1 and free form text in PGN
>> tags or comments. No special structure, no performance
>> cost, fast searches.  Very flexible.
>
> My point is that u is already taken by another meaning. I'd
> need some more of those kind.
>
>> 2. Add user flags from u1 to u16. Question is how to
>> standardize their use ?
>
> That's why I'd propose to add the meanings of those "per
> base" and add some descriptive strings to the base as well
> for the user to remember easily.

I have a few free bits in current index. So what I propose is to add 6
user customizable bits and corresponding fields. So those are bits u1
to u6 each having a text associated of 8 chars. This text explains the
meaning of each bit and is related to each base. Current user bit
present in v3 base does not change.

Does this sound ok for you ?

> In the case mentioned above one could just require to set
> flag 1 if an exercise is solved, flag 2 for a wrongly solved
> one and so on, but it would get it's meaning only in context
> of this specific base.

Not a good way to proceed. More efficient is to set the Tactics flag
to 1 and then a PGN Tag like [ExerciseSolve "1"].

>
> For my ref base e.g. I could define 1 to be "book
> annotation" or whatever.
>
>> (or leave u1 to u16, ugly isn't it ?).
>
> This would be ugly, yes. That's why I proposed a
> "translation table" of some bytes length for the base header
> where I can specify a short string for their meaning.
>
>> Small penalty in RAM (few MB). Fast searches. Certainly
>> poor user interface unless usage is precisely defined and
>> structured (and then less flexible).
>
> The fast searches would hep me a lot for my cross
> referencing. I have to flag the games as otherwise I can not
> retrieve them from my ref base. One usage is that I copy
> games I've in a book to a PGN file I transfer to my Palm if
> I want to work through it. If I use header search for
> unflagged games and just scan for [Ref "xyz"] it takes a day
> or two to find them in a larg DB. Therefore I flagged the
> games and then limit search to those flagged.
>
>> 3. Add a 32 bits ID for each game (in game index) that
>> points to an extra file containing meta data (could be
>> XML, binary, whatever).  Small penalty in RAM (few MB).
>> Poor performance when searching in this extra data. Very
>> flexible.
>
> This would be a good idea if one wants to add a larger chunk
> of data that is only of interes for display and not for
> searching.
>
> I'd like it "the other way round" e.g. that I could add some
> id for a set in the external file to the header of a game to
> reference a book. Say I've some set like
>
>     ID       : 5600769
>     Author   : Bronstein, David
>     Title    : Zurich international chess tournament, 1953
>     Publisher: New York : Dover Publications
>     Year     : 1979
>
> I could add something like
>
>     Ref "5600769, p.25"
>
> and e.g. hovering 5600769 could resolve to the full record.

We already talked about that point, and Game ID is far from easy to
implement. For example how do you merge 2 bases ? Cross referencing
would certainly be broken or hard to maintain.

Pascal

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users

Reply via email to