Location of FD-Related Files

[stev_hav]

It appears to me that the primary location of both "convention" and "convcard" ought to be the server, as opposed to individual members' computers.

 

Fairly-detailed versions, of relatively few systems, are likely to be developed. These are likely to include several thousand individual sequences; most members will use the great majority of these "as is", with relatively few modifications.

 

Whatever the allocation of system content among "convcard" and "convention" files, total size of each system is likely to be on the order of several megabytes. At best, inconvenient to repeatedly download to members' computers; especially where dial-up connections are involved, tending to consume several minutes.

 

Material developed and supported by BBO would reside in one group of directories; itself altered ONLY by BBO action. Members wishing to replace selected portions of this would develop "overlay" conventions; these would reside in another group of directories, organized by member userid. Ex: a partnership sees fit to use a 2nt response, to 1M, as natural and game-forcing; balanced, most likely with a doubleton in the major. To do this, it would record the altered sequences in the form of a "convention"; by appropriate entries in its "convcard", it would cause this to replace the affected sequences in the standard system.

 

Per-member space occupancy, for this purpose, would tend to be insignificant.

 

I would see actual editing of sequences being done on members' individual computers, with the results being uploaded to the server (for storage under member's userid). Both for efficiency in the editing process, and to permit actual editing to be done in the absence of an internet connection.

 

I do have a few thoughts concerning the details of organization--file naming standards, etc. At this point, I would like to hear others' views . .

[uday]

First, let me apologize for not moving fwd w/the FDO stuff. This is our busiest week of the year, and we're short handed (with FG messing about in Portugal). In addition, we're having a bad-hair day every other day, it seems like! Failing hardware, 3-year old bugs suddenly activating, squawk, squawk, squawk

 

 

Anyway, I agree that the primary respository could be the server.

 

There are currently 3 types of FDO objects.

 

1. Stock (system-supplied) conventions

2. Stock convention cards

3. User-supplied convention cards

 

Stock objects reside on a database. they are delivered to all users upon login as part of that login "blast" we suffer through when we login to BBO. Actually, a list is delivered, and the client aks for the ones it is not up to date with.

 

User-supplied cards are created on a users PC. when the user USEs a user-supplied-convention-card, the server fetches a copy from him, and sticks it into the database if it doesnt already have it. So if you USE a private card, then log off and USE it on next login, we dont need it again, we already have a copy.

 

We dont currently have an interface to manage this list of private cards in the database. I anticipate using a web page (or popup web page, like lobby news) to deal with it so that a user can access other people's cards. I also expect that when the client logs in, it will be given a list of its own cards, tho this gets complicated when the client has a different version of the same card -- which one wins?

 

 

The client caches the stock cards. it does not cache other users' cards beyond the lifetime of the login session, IIRC. Maybe FG will keep them around for a bit longer to save downloads.

 

I don't think FDO objects will ever get into the megabyte range but who knows.

 

FG does not currently support user-created-conventions, and perhaps he should.

[stev_hav]

I do appreciate Uday's timely, and relatively-comprehensive, reply.

 

It appears to me that--prior to attempting to actually exercise FD, we need to better understand the implications of what will actually be happening.

 

The server-to-client transfer of "stock" components at login time, will presumably be controlled by comparing last-change dates between client and server. If the server has a later version, a replacement copy will be transferred. This implies that every user will be maintaining a duplicate copy of all such components. As the number of "stock" components increases, transfer time and space occupancy could become significant issues; especially if the client is on a relatively slow internet connection. Probably manageable, at least short-term, by restricting both the frequency of stock-component updates and the number/size of such components.

 

Given the current lack of support for user-created conventions, the only way to make their content available will be to include this in user-created convention cards. Assume that we have "stock" components defining BBO Standard (specifically including strong jump-shift responses to majors), and that a user wants to add Bergen to this.

 

Altho it's not 100% clear, it seems safe to assume that, if the convention card names the stock components first, FOLLOWED BY the sequences affected by Bergen, the user-supplied content will be effective.

 

The requirement that detailed sequences be included in user "convention cards" might result in their becoming rather lengthy. Very possibly, creating a transfer-time issue, especially for tournament play.

 

Related, HOW MANY convention cards will the server be able to retain for each user? Only one, or more? If more than one, how will the server determine whether it has an up-to-date version of the one being "used"?

 

I DO believe that the basic design of FD is fundamentally sound; likely to, long-term, attain and surpass its stated objectives. Even so, discussion of forseeable short-term problems does seem worthwhile.

[hrothgar]

It appears to me that--prior to attempting to actually exercise FD, we need to better understand the implications of what will actually be happening.

 

The server-to-client transfer of "stock" components at login time, will presumably be controlled by comparing last-change dates between client and server.

Any design that requires end users to understand this type of implementation detail is doomed to fail...

 

In all honesty: How many bridge players do you think have a clue what any of this means?

[uday]

Don't look at me (if you were) , I was answering a tech question ")

 

I think users won't need to think about this stuff. the vast majority of users will select from one of a few standard convention cards like 2/1 or sayc, and add a few standard conventions

 

Sure, behind the scenes, FGs code will be making sure their copy of stayman matches mine or whatever but they dont need to care

[stev_hav]

It appears to me that--prior to attempting to actually exercise FD, we need to better understand the implications of what will actually be happening. 

 

The server-to-client transfer of "stock" components at login time, will presumably be controlled by comparing last-change dates between client and server.

Any design that requires end users to understand this type of implementation detail is doomed to fail...

 

In all honesty: How many bridge players do you think have a clue what any of this means?

My point is that the current version of the design appears to be somewhat less than optimal. Forseeable consequences being that user disk storage, user-server communication links, and perhaps even server resources may well become overloaded; rendering use of FD at best inconvenient--if at all feasible.

 

To make effective use of FD, end users WILL need to understand how to access and update convention-related files. Most will, as a practical matter, base their convention cards upon one of the "stock" systems; even so, there will be a tendency to make at least a few modifications.

 

At least IMO, better that such issues be at least discussed . .

[barmar]

I can't imagine client disk space becoming an issue. There are only going to be a handful of stock convention cards, but let's assume a worst case of 100 cards and they're all huge, such as 1MB. That's only 100 MB, which is nothing these days, when consumer disk sizes are measured in 10's and 100's of gigabytes. More likely it will be under 10 MB.

[stev_hav]

I can't imagine client disk space becoming an issue. There are only going to be a handful of stock convention cards, but let's assume a worst case of 100 cards and they're all huge, such as 1MB. That's only 100 MB, which is nothing these days, when consumer disk sizes are measured in 10's and 100's of gigabytes. More likely it will be under 10 MB.

I tend to agree that client disk space, in and of itself, is unlikely to become a significant issue.

 

Transfer time, however, might well be another matter entirely. If a fairly modern dial-up connection (28KB) is involved, transfer of a 1MB file will take at least 5 minutes; it is distinctly possible that several such files might need to be transferred. Not to mention issues which might arise due to a file being updated, on the server, while the client is already connected.

[barmar]

Not to mention issues which might arise due to a file being updated, on the server, while the client is already connected.

Hopefully it doesn't overwrite files in place, but instead installs a new file and swaps names quickly. This way, downloads that are in progress will continue with the file they started on, and it will get a consistent file, although it may be the previous version.

 

Another way to deal with this is to get the file modification time before and after downloading. If they're different it means the file was rewritten during the transfer, and you need to download again. This prevents the "previous version" problem mentioned above, but means that it could take twice as long to download the file in these rare instances.

[stev_hav]

Not to mention issues which might arise due to a file being updated, on the server, while the client is already connected.

Hopefully it doesn't overwrite files in place, but instead installs a new file and swaps names quickly. This way, downloads that are in progress will continue with the file they started on, and it will get a consistent file, although it may be the previous version.

 

Another way to deal with this is to get the file modification time before and after downloading. If they're different it means the file was rewritten during the transfer, and you need to download again. This prevents the "previous version" problem mentioned above, but means that it could take twice as long to download the file in these rare instances.

The issue which I really had in mind would arise when:

 

A. North and West log on at 8:25, and gets current versions of all relevant files.

B. One or more of these (ie, "stock" files on the server) are updated at 8:30

C. South and East log on at 8:35, and receive the now-current versions.

 

One way or another, the fact that the North/West copies of replaced files are now out of date must be both recognized and dealt with.

 

Recognition, in and of itself, would be relatively straightforward; any user who had logged on prior to file-update time would be known to have an out-of-date version.

 

Corrective action, especially at high-activity times, might be somewhat more difficult. Transmission of numerous copies, of sizable files, would tend to require quite a bit of bandwidth; delays would be forseeable.

 

Most likely, it would be best to do file replacements ONLY during periods of low system activity. And, by some means, notify clients of such actions and determine whether a given client is actually relying upon the involved files. If I and opponents are playing a natural system, and some files for a strong-club system are replaced, this will not directly affect play at our table; transmission of copies of such files, to the players at our table, can be deferred "until convenient".

 

I do not disagree that, at least short-term, transmission of files to clients is a viable approach. Even so, it does seem advisable to consider/discuss forseeable complications.

[uday]

I expect that alterations to stock FD things will be a very low frequency issue, and we'll try (as with private/public club lists) to update these only during maintenance

[luke warm]

sorry to be so dense, but i'm confused... at one time we created the base FD system, then other .bss files as conventions, and we then used the merge command... then fred (i think) said no need for that, since the FD app was integrated into bbo proper

 

then he asked that we send our files to uday, but what files? for example, i have a base 2/1 FD file and then i have a 2 way ckback conv file, a bergen raise conv file, a 1nt conv file, etc... merging them wouldn't help if the server houses only the base file, eh? and from what i've read here, uday doesn't want us to send *all* of our convention files

 

should we no longer create convention files and just build one large system file? and if so, do we then send that to uday?

[stev_hav]

sorry to be so dense, but i'm confused... at one time we created the base FD system, then other .bss files as conventions, and we then used the merge command... then fred (i think) said no need for that, since the FD app was integrated into bbo proper

 

then he asked that we send our files to uday, but what files? for example, i have a base 2/1 FD file and then i have a 2 way ckback conv file, a bergen raise conv file, a 1nt conv file, etc... merging them wouldn't help if the server houses only the base file, eh? and from what i've read here, uday doesn't want us to send *all* of our convention files

 

should we no longer create convention files and just build one large system file? and if so, do we then send that to uday?

In my opinion, any viable implementation of FD will need to support user-defined conventions. Specifics--where these will be housed, and how they will be logically merged with "stock" conventions--are unclear at this point. It does seem safe to assume that, at some point in time, appropriate directories will be set up, and a procedure for searching these defined.

 

One of the more-logical possibilities would be that convention cards consist primarily of references to conventions; for example:

 

+bbsb_we_cp_1c1d minor-suit openings

+bbsb_we_cp_1h1s major-suit openings

+bbsb_we_cp_1n1n 1nt

+bbsb_we_cp_2c2c strong 2c

+bbsb_we_cp_2d2s weak two's

+bbsb_we_cp_2n2n 2nt

+bbsb_we_cp_3c3s preempts

+bbsb_op_cp_1c1s opponents open one of a suit

+bbsb_op_cp_1n1n opponents open 1nt

+bbsb_we_cp_flannery Flannery 2d

+bbsb_we_cp_drury 3rd/4th seat major openings

+bbsb_we_cp_bergen bergen raises

 

Each of the named files would be searched for, first in a user-controlled and then in a stock-component location. Conflicts, as between weak 2d and Flannery, would be resolved by using the later-specified convention. Because Flannery was specified after weak twos (and major-suit openings), its sequences would take precedence. All sequences beginning with 2d, 1h-1s, etc., would be as specified in Flannery.

 

For right now, it would seem advisable to continue developing individual "conventions", giving these consistent names, and keeping them in a "conventions" directory on a local computer. And, short-term, manually merging these into "convcard" files.

 

I should emphasize that I am expressing only my own opinions; I am not in any position to speak "officially" for BBO.

 

I have, as a matter of interest, uploaded most of the above-named files to a "BBO_FD_Files" discussion group, on Yahoo.