Start up Jester. If you have that symlink to it or put it in your path, that is as simple as typing jester at the command prompt. (Can anyone tell me how to make a Gnome/KDE icon for Jester?) Once it's running, you need to open a database.
You may need to download a database first. In the future, I will include more samples with the software. The easiest way to do this is to tell Jester to "Open Url" and then "Save as". You'll need to use that "File" pull-down menu for both. The "Open Url" option will ask you for the location of a database's indexfile. Every bmd has one and they usually have .bmd at the end of their names, though it's not necessary. It's usually called (something).bmd . That file is like a main config file. It contains the names and locations of all other necessary files, so Jester can do the rest from there. Just remember to put http:// at the beginning of the url. When Jester asks for a url, just type this:
That's my sample database. I built it from reading dmoz. I intentionally left it incomplete so people could practice populating a database. If everything goes well, you should see some of the tables in a tabbed notebook. Once it's open, a quick "Save As" will make a local copy of the database on your harddrive. "Save As" is going to ask what directory on your harddrive to save the database in. Now that you have your own instance, in the future, you can open it using the "Open" option instead of "Open Url". To figure out what just happened, read the file overview part of the Developer Intro.
You already saw what "Open Url" does when you downloaded a bmd. The "Open" command is similar, except it assumes the bmd is already on your harddrive. "Save" and "Save As" do what you'd expect. They save any changes you make through Jester. In database lingo, they are similar to a "commit". "Close" will remove the current database from Jester's memory. You can have several bmds open at a time, so memory can get scarce quickly. "Quit" should close everthing and kill Jester. No surprises there, eh.
When you open a bmd, Jester will show you one of the normal tables in a tabbed notebook. Most of the other tables are hidden behing the other tabs, but not all of them are shown here. You see, Bmd tables fall into three categories called dataspaces. They are normal, reject, and static. The distinctions may not be clear right now, but let's just say the three dataspaces are updated differently when the hostsurvey runs. The Normal and Static tables are shown together, and they're ususally the first to be shown when a database opens. The Reject tables, however, are shown in a separate tabbed notebook. The top two options of the View pull-down menu will let you switch between the dataspaces revealing both tabbed notebooks. The rest of the View menu contains the indexfile names of whatever bmds you have open right now (which could be none). Clicking on a name will reveal the tables of that database.
The Edit pull-down lets you make changes to your database. "Insert record" will let you create new records for your favorite web sites. These changes should spread to other people's databases, too, if someone has you hostlisted. I'll explain "hostlisted" in the next section. "Delete record" will remove a record from your instance of the database. You have to select a record first by clicking on a line number button. "Unreject record" sort of undeletes records in a way. You have to do it from a reject table, though (remember the View menu).
At this point, it's getting important to understand that any changes you make only affect your own instance of the database. You can only change what's on your harddrive. Your additions and deletions normally spread to other people eventually, but it happens indirectly. So you can treat your instance as your own personal database, but bear in mind that it can influence others. You have some choice in the matter when it comes to deletions. Jester will ask if you want to prevent the spread of a deletion by making a "personal reject".
Deletions from Normal (and some Static) tables spread through Reject tables. It's time to learn the distinctions. The Normal tables are the ones you'll be using most of the time, but to maintain them, you'll have to look at the Reject tables every now and then. First of all, Normal tables are associated with Reject tables in Normal-Reject pairs (We need a better term for that). What that means is, whenever a record appears in a reject table, it is not allowed to appear in the partner table. When you delete a record from a normal table, what really happens is you insert that offending record into the partnered Reject table. That way, the Reject tables work as a censoring system for the Normal tables. This is a voluntary censoring system, though. Your rejects try to spread to others, but there's no guarentee that other people will agree to it.
You should notice that every Reject record has a status code field. That code indicates how Bmd should behave in response to the reject. Status codes "a", "p", and "x" will remove a matching record from the partner Normal table. Status code "d" stands for disabled. It is the inactive version of "a" and "p" status coded rejects. If a reject has status code "d" then the partnered Normal table is still allowed to contain that record. When you "Unreject Record", what happens is you change the status code of a reject to "d" and then insert the pardoned record back into the appropriate Normal table. If you ever get undesirable rejects from other people, then just disable them. The "x" rejects are for dead links. If someone reports a deadlink and you can still reach the site you should disable that "x" reject with a "y". Dead links have dedicated status codes so that future software can distiguish them from the petty arguing of us humans.
The Static tables are mixed in with the normal tables. They usually don't have a Reject table, though you could give them one. It wouldn't have much effect. The Static tables do not receive automated changes from other users like the Normal and Reject tables. Changes you make to Static tables don't spread to other people either.
First, we all share our databases on the Internet somehow. I don't really care how that happens, so I just use web sites. We all share our bmds on web sites. Use the View pull-down menu to look at the Normal/Static tables and find your hostlist table. Your hostlist table is the list of people that you check each day for updates. The hostsurvey program is supposed to run 24-7 and download each of the indexfiles listed in the hostlist table. The hostlist table is sort of a config file for the hostsurvey program in that way. Hostsurvery will then read your hosts' indexfiles and syncfiles to find the changes they made today. It automatically updates your database according to the differences between your instance and the others listed in your hostlist table.
In the future, Jester will show you the updates from each host and let you approve/deny them one by one. Each host is normally checked once per day at the nextchktime. That nextchktime value may look readable now, but if you want to change it, you have to enter a time in epoch relative form. You can change the nextchktime fields to something more convenient, but be careful. The interval field is probably 86,400 which is the number of seconds in a day. That means the nextchktime will increase by 86,400 secs or one day after an update. If you want to check a host once every week, change the interval to 604,800 (the number of seconds in a week). The interval is normally 86,400, but you can set it to whatever you want.
Read through the database every now and then, and approve/deny updates, but remember that the new records and the active/disabled rejects might spread to other people. Personal rejects don't spread, though. They are just for you. Other people can see them, but they don't affect others. The static dataspace is for tables that hostsurvey should ignore. They will not receive automated updates. You can make a reject table for one, but it has little impact. Hostsurvey will never add or remove stuff from a static table.
Bmd is probably going to be a labor of love to some people, but little more than a weird search engine to most others. The database quality depends on the judgment and attention of its users. That means you need to watch out for crap that doesn't belong. Please delete stuff that is offtopic or just crap. Don't worry too much if people will disagree, because I have already accounted for that in my design. I know people are going to disagree about virtually everything, so I've designed Bmd to support human disagreement and benefit from it. You may be able to influence other peoples' instances of a database, but ultimately, you can only hurt your own instance with any significance. Disagreeing with others doesn't make you a creep. The only creeps are the ones who want total, undefiable control over what other people see, use and do, but my design doesn't allow that. The point is, Bmd needs your help to keep its high content quality, because I cannot make a software system that knows what does and does not belong in a bmd. Bmd relies on your judgement for that.
Jester plays very little part in this. It helps maintain some consistency across the platform and helps you accept and deny incoming changes, but it will not send outgoing information. In fact, you never really "send" updates by your own will alone. To spread updates, you must share your database files on a web site, but that's just your half of the job. Just because you are sharing a database doesn't anyone is watching. To really spread updates, other people have to put you in their hostlists.