stev_hav

The correct url, for bbo_fd_files, is: BBO_FD_Files Original version had an extra http:// . .

I have set up a Yahoo discussion group, at: BBO_FD_Files for basically the same purpose. Difference being that Yahoo procedures (and my definition of the group) allow anyone to join the group, upload files, and update any of the user's own files. As noted in the description, I had planned to de-implement this as soon as BBO began actually supporting similar uploads. Almost three months having passed, I am now publicizing its existence in this forum. Anyone wishing to upload files should feel free to do so. When/if BBO begins to support a comparable capability, I will transfer the then-current content (of BBO_FD_Files) to the BBO-supported area.

The next release of BBO/FD should include a significant number of "stock" FD files; both convention cards and conventions. This is due to be released any day. Once the release is actually done, every time you sign on to BBO your copies of the "stock" files will be brought up to date. (This is actually happening under the current -- 4.5.4/1.1.9 -- release, but relatively few files are available). It seems "probable" that, with the next release, it will be feasible to start getting some actual live-play experience with FD.

I am in substantial agreement with hrothgar's last post; a couple of points . . It may well be advisable to support multiple categories of named conventions. In addition to the officially-supported "primary" list, perhaps allow any interested user to develop a "personal" secondary list, in an area identified by userid. To contain items such as hrothgar's "misiry preempts"; especially useful when a member maintains convention cards for each of several frequent partners. Somewhat related, I would question whether it's truly cost-effective to have the server track frequency of module usage. It seems more likely that, over time, frequent users would develop a pretty-reliable "feel" for development priorities.

It seems to me that these suggestions are quite practical, but limited *specifically for ACBL tourneys*. But let's not forget that FD is not geared specifically to ACBL and Nort-America: the conventions that are popular in USA are not as popular in other parts of the world (e.g. Capp and DONT, or Bergen raises , to use some of the given examples.) :) I hadn't really given all that much thought to "internationalization" issues, but my thinking would be along the following lines. At least initially, assume use of English as the only supported language within FD. In the relatively-near future, the "czars" should publish a "primary" list of the conventions for which they intend to develop definitions (including a short description of each). A mechanism for handling proposed additions might also be implemented; probably allowing members to simply develop/upload any such into a secondary area, subject to a restriction against duplicating any name on the "primary" list. As time permitted, the "czars" would review new additions to the secondary area, and take one of the following actions: A. Mark the addition as "accepted" and copy it to the primary area. B. Determine that the addition is a "synonym" for something which is already on the primary list. Software permitting, add the new name to the primary list, with a cross-reference to the original entry. C. Determine that the addition should not be added to the primary area, so mark it, and so notify the submitter. Most likely, leave the addition in the secondary area, allowing (only) the original submitter to modify or remove it.

One additional comment regaridng a standardized vocabulary: Don't make the best the enemy of the good... I doubt that its possible to create a vocabulary that will handle every possible case. However, if you're able to handle "common" cases this will meet the needs to 90% of the users... A few thoughts, concerning the handling of bids whose meaning depends upon opponents' agreements. Any useful approach would need to: A. Be straightforward enough to be understandable, and to be implementable with a reasonable degree of effort. B. Be comprehensive enough to cover a high percentage of reasonably-forseeable situations. C. Be flexible enough to support extension/expansion, as dictated by experience. It appears, to me, that the list of frequently-encountered partnership agreements is not all that long. It would tend to include most whose names appear on the standard ACBL Convention Card, and "not all that many" others--Bergen raises, responses/rebids to strong 2♣, Flannery/Multi/Mini-roman 2♦, defenses to opponents 1N, etc. Thus, it would appear entirely feasible to develop and publish a list of "basic definitions", for such agreements. Each entry would specify: A. A name, by which the agreement is to be recognized. B. The call or calls which initiate the convention. At least initially, only those which actually have the conventional meaning. For example, the definition of "Bergen" would specify only 3♣ and 3♦; on the assumption that references to this would be made only in auctions beginning with 1M-(P). C. The normally-expected hand pattern, and strength. As necessary (multi 2♦, major-suit Michaels, etc), supporting multiple entries. D. Frequently-occuring sub-sequences. Probably defining only one such per entry; where multiple options exist (2♥/2♣ either natural or a "bust" response), tending to create a separate entry for each option. During entry/editing of each side's own agreements, a dropdown list would show the names of all "basic definitions" for conventional meanings of a call. In its simplest form, a call such as 2♥ would present "all defined" meanings for the call (transfer to spades over partner's 1nt, capp/dont over opponents' 1nt, flannery 2♥, etc). If bidding side's agreements matched any such, the meaning would be selected and recorded. (Altho it would "seem logical" to show only the meanings consistent with the auction to date, this would tend to complicate the process of definition, and most likely the software . . ). Another dropdown box would show "all defined" opposing agreements for opponents' last action (bid, double, or redouble). When the meaning of bidding side's call depended upon opponents' agreement, the applicable agreement(s) would be selected. A specific example. Assume three possible definitions--MINI_1N, WEAK_1N, and STRONG_1N--of a 1N opening, and two possible defenses--CAPP and DONT. Bidding side might well see fit to "mix and match" 1NT size, depending upon seat and vulnerability. For each separate occurence of a 1N opening, it would select a definition. (Or, if no definition were at all applicable, make no selection). If defending side wanted to bid naturally over MINI_1N, use CAPP over WEAK_1N, and DONT over STRONG_1N, it would make appropriate entries in its specification of double, and 2-level overcalls. Over opponents MINI_1N, it would select no agreement; CAPP over WEAK_1N, and DONT over STRONG 1N. Specification of an agreement "ought to" copy in all related sub-sequences; especially useful where various forms of Blackwood are involved. In practice, it might well be advisable to support "customized" definitions of the named agreements. Covering "minor modifications", which retained the basic meaning. Hopefully, an implementable version of "the good" . .

Somewhat related, it appears that the number of "reasonably forseeable" sequences, which might logically be specifically mentioned in an FD file, is quite large. Assume the following--somewhat over-simplified--conditions: A. Vulnerability is irrelevant. B. Only sequences in which the dealer (North) opens the bidding are considered. C. Both sides are playing identical versions of SAYC, using only a minimal list of conventions (Stayman, 2-suit transfers, 2nt forcing major raise, 2c strong/2d waiting, negative doubles, unusual NT, Michaels, Blackwood). North will choose one of--at least--ten different calls with significant frequency. East will then choose one of--at least--twelve different alternatives (pass, double, minimal or single-jump overcall). South will then choose from some five alternatives, after which West will choose from some five. Implying that some 3000 first-round sequences should be regarded as "reasonably forseeable". Assuming that each player has as few as two logical-alternative calls on the second round, we now have a total of 48,000 such sequences. Attempting to manually key any such volume into FD, let alone issues related to reviewing, distribution, etc., appears rather impractical. Undisputed that only a relatively-small percentage, of all "reasonably forseeable" sequences, occur with any significant frequency. It seems probable--altho I have done no relevant calculations/research--that the highest-frequency 1-2000 sequences would occur in 99+ percent of all relevant auctions. In other words, the remaining 46-47000 sequences would occur in less than 1% of auctions; and could be, at least for the purpose of initial FD creation, safely disregarded. It appears that some "guidelines", as to selection of sequences which need to be actually included in FD files, need to be established. There appears to be a fundamental problem in this area. As best I am able to determine, it is necessary to assume one--and only one--opposing agreement concerning any given call. Opponents' 1c openings have to be assumed either "natural in principle", or "forcing"; bidding side's agreements concerning double, 1nt, and 2c tend to be significantly different. Short-term, about all that can be done is to make an assumption as to opponents' agreement. It may, sooner or later, be desirable to develop a list of frequently-encountered conventions, and to accept specification of this on both bidding side's and opponents' calls. Bidding side could then specify one meaning for "double" over a natural 1c, and an entirely-different meaning over a forcing 1c.

Somewhat related, it appears that the number of "reasonably forseeable" sequences, which might logically be specifically mentioned in an FD file, is quite large. Assume the following--somewhat over-simplified--conditions: A. Vulnerability is irrelevant. B. Only sequences in which the dealer (North) opens the bidding are considered. C. Both sides are playing identical versions of SAYC, using only a minimal list of conventions (Stayman, 2-suit transfers, 2nt forcing major raise, 2c strong/2d waiting, negative doubles, unusual NT, Michaels, Blackwood). North will choose one of--at least--ten different calls with significant frequency. East will then choose one of--at least--twelve different alternatives (pass, double, minimal or single-jump overcall). South will then choose from some five alternatives, after which West will choose from some five. Implying that some 3000 first-round sequences should be regarded as "reasonably forseeable". Assuming that each player has as few as two logical-alternative calls on the second round, we now have a total of 48,000 such sequences. Attempting to manually key any such volume into FD, let alone issues related to reviewing, distribution, etc., appears rather impractical. Undisputed that only a relatively-small percentage, of all "reasonably forseeable" sequences, occur with any significant frequency. It seems probable--altho I have done no relevant calculations/research--that the highest-frequency 1-2000 sequences would occur in 99+ percent of all relevant auctions. In other words, the remaining 46-47000 sequences would occur in less than 1% of auctions; and could be, at least for the purpose of initial FD creation, safely disregarded. It appears that some "guidelines", as to selection of sequences which need to be actually included in FD files, need to be established.

But it might still be sensible to make the "official" BBO FD files conform to some standard, while allowing more flexibility for files created by the users. I fully agree that the proposed list of abbreviations is rather lengthy, and that many BBO users are likely to be unfamiliar with it. Even so, the advantages of consistency do appear to be substantial. Very-possibly best that Inquiry review his list; remaining consistent with the WBF abbreviations as far as possible, but adding new ones where necessary. Then post the revised list "for review and comment"; allowing others to propose revisions and/or additions. Once a consensus were arrived at, a convention to the effect that "official" FD files follow it in a consistent manner could be adopted. With fairly-straightforward modifications to BBO and/or FD, optional display of the spelled-out form could be supported. Allowing--at individual-user option--brevity for more-familiar entries, and completeness for less-familiar ones. In some cases, especially for less-experienced players, even the spelled-out form might not be entirely clear. As appropriate, "expanded" explanations--as long as a full paragraph--could be developed and published. Altho the initial version of the list should be "as complete as practicable", subsequent additions could be handled without significant difficulty.

Use of "consistent formatting and abbreviations" appears desirable for reasons entirely unrelated to some participants' unfamiliarity with English. At least IMO, it appears that the current/1.1.8 format will need to be enhanced; to transmit additional relevant information. Assuming that no such enhancement will be available in the near future, the best place to house such information is in the "description" field. It might well be advisable to adopt a convention, to the effect that "recommended" abbreviations be placed at the beginning of the description field, separated by commas and terminated by a delimiter. Everything after the semicolon being entirely free-form. In and of itself, this would result in abbreviations being displayed first; in the most-visible location. If consensus, as to the recommended list could be arrived at, development of audit software would be a quite-straightforward matter. In its simplest form, this would merely verify that the beginning of the description field--up to the delimiter--was consistent with the recommended list. In addition to promoting consistency, this would be quite helpful if a subsequent version of FD provided explicit support for some recommended-list entries. Such software could also verify that everything preceding the description was validly formatted and internally consistent. Specifically including verification that all bidding sequences are both themselves legal, and consistent with previously-specified sequences. An auction (opponents silent) beginning with 1S-1N-2S should logically be preceded by 1S-1N. A requirement, that all submissions pass audit-software validation, would appear to be quite desirable.

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.

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.

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.

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 . .

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.

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 . .

Agree completely... SAYC was able to ressurect itself from the dustbin of history based solely on the fact that Matt and Wirt needed a system and they found online documentation for SAYC... I very much hope that the advent of Full Disclosure lets us put a stake through SAYC's heart once and for all. At least IMO, a "basic" system--either BBO Standard-Basic or SAYC--is in fact worthwhile for specific and limited purposes. For individual tournaments--either "live" or online--it allows strangers to play together with little or no discussion of methods. As the basis for development of "sample" convcard/convention files, for use with FD, recording of the more-frequent sequences can be accomplished with relatively little effort. I have actually created, and sent to uday for posting, at least a "starter" version of such files. These are also accessible, in the form of actual files, in a Yahoo discussion group: BBO_FD_Files Membership in this group, including file uploads and downloads, is open to all. As mentioned in its description, this is intended to be short-lived; to be de-implented as soon as a comparable facility is actually made available within BBO.

When I first downloaded 4.5.0, the conv feature DID appear to be more or less functional. But, in last few hours, it shows ONLY the old cc. Please advise.

Into what specific directory(ies) are these downloaded? How is the determination that a given convcard or convention does, or does not, need to be downloaded, made? If this involves an exact match upon name, and a comparison of timestamps, how are differences between server and client clocks handled? Also, I just logged on (to 4.5.0) and the "conv" function is bringing up ONLY the old format convention card.

I've contributed a "skeleton" version of BBO Standard-Basic; which Uday will presumably be uploading. Is there any way to determine what convcards, and conventions, are available on the server for use? More/less related, in tourney play, do both sides have to be using 4.5.0 before alerts can be issued?

At least IMO, describing a "multi" 2d as preemptive, and 2h response as "non-forcing", would be highly misleading. Ordinary "preempts"--promising length only in named suit--need not even be alerted. 2d, on the other hand, pretty well DENIES d length; is either a major-suit wk2 or strong/balanced; needs to be so described. Description of 2h really needs to explicitly say pass or correct . .

This feature is already part of the plan. Fred Gitelman Bridge Base Inc. www.bridgebase.com PS Happy Birthday! Where do you intend that system files reside, during online play? It would seem "ideal" to house these on the server: A. To ensure that both members of each partnership are using the same file. B. To keep files available to those who use a desktop at home, and a laptop while traveling; avoiding any need to keep files synchronized. C. Possibly, at some future time, to serve as clear-cut evidence of a pair's actual partnership understandings. To assist in resolution of certain controversies, in higher-level at-the-table competition. (Assuming that at least appeals committees, and most likely directors, would have at-the-site internet access.) There would, however, be complications: A. Need to support upload/download and/or on-line updates; most likely both. B. Need to account for members' system files; both as to backup and space occupancy. Altho it appears that "on the server" would be long-term preferable, "on the client" appears to be both a feasible alternative and simpler to implement.

Have you completed enough of the keying to be able to estimate your final record count? I have just begun working on a comparable file, based upon "BBO Standard - Basic". All that I'm attempting to do, at this time, is record sequences beginning with 1c and 1d. I have keyed what appear to be the higher-frequency uncontested auctions, including "only some" of the more-likely slam-try sequences. It appears that, after suit agreement and using standard Blackwood, there are at least 55 logical sub-sequences from 4nt onward. (4 possible replies, after which asker may sign off, bid slam, or continue with 5nt . . ). And, that there are "quite a few" suit-agreement sequences, in which one partner is unlimited and may logically ask for aces. (Single raise, 2+ jump raises, 3 possible splinters, raise followed by cue bid/s, etc). In all likelihood, several thousand uncontested slam-try sequences. Not to mention possible competition. Each combination of opposing actions--even assuming that opponents subside below 3nt--would generate an additional copy of "all logical uncontested" sequences. It is "far from obvious", to me, that it would be truly feasible to make use of--let alone record--a file consisting of one record for each reasonably-forseeable auction. It would seem advisable to--in the relatively-near future--estimate the "maximum feasible" file size . .

I've begun attempting to develop an actual system file. Have begun by recording 1c and 1d openings, followed by uncontested auctions, assuming use of "BBO Standard - Basic". I have completed recording of the apparently-higher-frequency sequences; suit and NT responses, continuing thru the game level. Also some, but fewer than all, of the higher-frequency slam-try sequences. If there were some convenient place to post what I've developed to date, I would like to do so.

You will have one. I would just as soon not have to do this again, so if there are other suggestions for new "dispositions" please let me know :lol: Fred Gitelman Bridge Base Inc. www.bridgebase.com Assuming that you're planning to make "one last" revision to file structure and editor . . At least for the immediate future, it appears that information such as playing strength, distributions, etc., will need to be recorded in the form of "comments". If so, it would seem desirable to provide for (at least one) "non-displayable" comment area. Retained on the file, but not (at least routinely) displayed to opponents. Related, very-possibly desirable to implement some form of "alert" flag. Such that only specified values would result in any form of "self-alert" being displayed to opponents.