response 25 of 113:

Jan 3 17:16 UTC 2002

oh, that *is* a good point

response 29 of 113:

Jan 3 20:47 UTC 2002

For me it depends on whether I judge the item has "lasting value", or
not. If not, I forget it in the specialty conference.

response 31 of 113:

Jan 4 00:06 UTC 2002

The only problem with "!forget agora 78" is that I've no way of remembering
that it is item 78. :(

response 33 of 113:

Jan 4 03:44 UTC 2002

Re #31:  Sometimes the person linking the item is helpful enough to post a
response saying "Item 63 in the dentalfloss conference linked to item 14 in
the ferrari conference."

response 35 of 113:

Jan 4 13:53 UTC 2002

(Sure.  Just "join enigma".)

response 37 of 113:

Jan 4 15:42 UTC 2002

Jan, couldn't you use "ls -i" to find the inum of the linked item, then 
use:

   find /bbs -inum <the number> -print

to find the other linked items, and then use that information to forget 
those items?  Is that too CPU intensive?

response 39 of 113:

Jan 4 17:51 UTC 2002

Well, sure, but it would only have to do it if the item was linked, and 
probably further only if someone chose the "forget all links to this 
item" option.  It doesn't seem like it would come up a whole lot.  
Though also it seems like an oversight that Picospan doesn't keep track 
of links in the item file.

response 41 of 113:

Jan 4 19:28 UTC 2002

If you only had backtalk to worry about, then you could insert a record 
in the cache to indicate that an item had just been linked.  But how 
would this cache discover that a picospan user had linked an item?  I 
guess every time a backtalk user reads an item that backtalk knows is 
linked, backtalk could check the cache and if it's not listed there, 
then backtalk could issue the 'find' command.

response 43 of 113:

Jan 5 04:05 UTC 2002

Yup, that's essentially what I'd do too, but I'd write it in C and gain a few
efficiencies based on a certain amount of knowledge of the structure of
conferences that find doesn't have.

I spent some time thinking about this yesterday.  It's just ugly.  Note that
I'm trying to write software that works on more places that Grex alone. 
Though it is certainly normal to have all the conferences stored as
subdirectories of the same directory, that isn't always necessarily the case.
Even on Grex we've occasionally had conferences in other directories when bbs
is full (though that wouldn't really be a problem because if they are on a
different filesystem then they can't be linked to anyway).  So anyway doing
a find on the bbs directory (by the way, on Grex you should depth limit that
so it doesn't go into the indexdir subdirectories of the conference
directories) isn't a 100% general solution.  Much better to extract all
conference paths from /bbs/conflist.

If all you want is a "forget in all other conferences" command, then doing
an inefficient search each time isn't too bad a deal.  But it'd actually be
nice to have this information more accessible.  Like the item header might
say [linked to agora:34] instead of just [linked].  For that we'd need to
cache the information somewhere.

A decent cache would be a dbm file which uses file inode numbers as a key,
and as the value would have a string like "agora,34 coop,19 helpers,45".  The
backtalk link and kill commands would automatically update it.  If backtalk
notices that the link count of the item doesn't match the number of names in
the database, then it can assume someone changed things from Picospan and it
does the slow search to correct things (in the worst case - if the link count
just went down by one you could start by checking the items in the old list
to see if all but one of them are still there).  This gets complex, but not
too complex.

But the conference names are a problem.  Most conferences have more than one
name.  "agora", "winter", "agora20" etc.  Two of those three names change
periodically.  We'd really want the database to say "agora20:19" instead of
"agora:19".  Unfortunately, there only distinction between conference names
that will change and ones that won't change is in Walter Cramer's head.  So
to do this right, we'd want to find some way of flagging the cannonical name
of the conference from the others.  Should Backtalk's administrative tools
then enforce that rule?

Or maybe the cache should have the directory name instead of the conference
name in it.  This changes less frequently than the conference name.  But then
we need to do a reverse lookup to find the conference name everytime we want
to display the information.  Also ugly.

So maybe you just ignore then conference renaming problem, and let the cache
repair code I mentioned above clean things up when the conference renames.

Of course, using a dbm file for the cache has a certain portability cost. 
Currently Backtalk uses dbm files only in some configurations, so on many
systems it can be built without using dbms at all.  It already has support
for about 6 different dbm packages, and most Unixs have at least one of those
so this wouldn't be that big a problem.  I could also make the whole link
cache thing a compile time option, so people who didn't have a working dbm
package could build Backtgalk without it.

So though there aren't any really difficult problems here, it's a pretty big
chunk of work to do this right.  I think I've got higher priority projects,
so it probably won't happen soon unless someone else does it.  (Backtalk is,
after all, open source.)

response 45 of 113:

Jan 8 19:16 UTC 2002

4.0.2

response 47 of 113:

Jan 8 20:10 UTC 2002

(I suspect that is "news.itd.umich.edu", which has one of the more complete
collection of groups.  It is not currently available to ComCast cable
customers because Comcast has not yet published a list of AA/Ypsi IP
addresses.)

response 49 of 113:

Jan 8 20:53 UTC 2002

Re #46:  No, Grex doesn't carry newsgroups any more.