response 50 of 112:

Oct 18 19:09 UTC 2004

RSS is something I want to do, but Picospan isn't in the way of that
one.   All I need to do for RSS is respond to an HTTP request with a
list of items presented in a specific format.  Backtalk can do that
easily.  The hard part is the semantics.  Which items should I list? 
How long do I continue listing items?  None of this is terribly clear. 
However, Picospan is not in the way of doing RSS.  Backtalk can handle it.

It should be noted that the Fronttalk on oldGrex is an older version
than the Fronttalk on nextGrex.  It has some bugs that the current
version does not have, but the ones John reports are new to me.  But
fixable.

I'm fairly confident that Picospan will not be buggy under OpenBSD. 
Backtalk as configured on Grex has complete data consistancy with
Picospan.  Backtalk on M-Net has complete data consistancy with Yapp.
Backtalk in other places is compatible with neither.  Fronttalk doesn't
access most of the data - it accesses Backtalk which accesses the data.
It does interpret ".cfonce" and ".cfrc" files, which it strives to do in
a Picospan compatible manner, but there are still bugs in this.

As long as Picospan is running on Grex, I'll keep Fronttalk/Backtalk
compatible with it.  If it goes away, I'll keep a look and feel closely
compatible with traditional Picospan for those who prefer that
interface.  But development of new features will become much easier.

response 52 of 112:

Oct 19 01:04 UTC 2004

STeve and I installed picospan today.  It is currently what you get when you
run 'bbs'.

It wasn't entirely configured Grexishly - wrong path name for the /bbs
directory, but that was fixable with a symlink.  I'm slightly worried that
there might be other configuration changes.  I should probably spend some
time figuring out what kind of file locking it is configured for so I
can be sure Backtalk is still compatible.

response 54 of 112:

Oct 19 01:36 UTC 2004

Too late.  We're locked into the 1970's forever now.  :-(

response 56 of 112:

Oct 19 06:53 UTC 2004

Will the new Grex have the following: elm, lynx, pico, and pine ?
Thanks.
Ahmet Toprak

response 58 of 112:

Oct 19 09:17 UTC 2004

Re #50:  Hmmm...  I can envision some things that one might want to
do with RSS that could be difficult if you have to maintain Picospan
capability.  For example, a user might want to be notified whenever
a particular item gets a new response.  The obvious way to do that
would be to associate an RSS "feed" (XML file in a particular format)
with the item, the user would subscribe to this feed in their
news aggregator, and the feed would be updated whenever a response
is added to the item.  I'd think this would be a fairly easy feature
to add to Backtalk, but impossible to add to Picospan since we can't
modify it.  The result would be that the feed would be updated only
when responses are added through Backtalk, not when a response is
added via Picospan -- an unsatisfactory situation.

Besides updating an RSS feed, there might be other "events" that we'd
want to associate with the posting of an item or response - e.g.
updating a search index, a database entry, things like that.  As
long as we support a response entry method that we can't modify,
we're effectively prevented from doing that, and I see that as a
big problem in the long run.

response 60 of 112:

Oct 19 14:42 UTC 2004

The 'feed' doesn't have to be a static XML file.  It can be generated by a
CGI.  If backtalk is that CGI, it would have no problem generating a current
response list for that item in RSS format. including any Picospan responses.
Of course, RSS works by polling, so if lots of people are polling, this can
add up to a lot of computation.  A static file would be more efficient, and
would not be possible while Picospan exists.

John mentions the idea of updating a database entry when a new posting is
made.  This is another one that Backtalk already partially implements. 
Backtalk is already capable of talking to an SQL server - it can work with
either MySQL or PostgreSQL.  Code to keep conference sum files in an SQL
database already works and is being used at http://www.greatgreenroom.com .
Code to keep item indexes in SQL is partially implemented.  Someday I may
have an option to move all the conference data into SQL.  The advantage of
having indexes in SQL is that it becomes posible to make much richer kinds
of queries aganst the database.  Like this would be a nice one:

    Show me the 10 items on the system which have had the most responses
    in the last 2 days from people who are not on my twit list.

Still, this could all be done while Picospan is around.  When a new post
is made via Backtalk it would write to both the SQL database that it uses
and the sum file that Picospan needs.  We'd have a background process
babysitting Picospan - it periodically polls all sum files to watch for
new items or responses appearing, and checks that they are in the SQL
database.  If not, it runs whatever processes you want to have run when
a new posting is made.  It's a little more complex than that, but it's
do-able.

The other area where Picospan is a problem is in item formats.  If I
ever want to store more data than Picospan does, then I can't put it
in any of Picospan's files without making Picospan croak on it.  I usually
solve this with parallel files.  You you are a regular Backtalk user, you'll
find that you have two kinds of participation files - .agora45.cf is the
Picospan participation file.  .agora45.cfx is the Backtalk participation
file, that contains additional data that would make Picospan choke.  On
systems where there is no Picospan or Yapp, Backtalk uses just a single
file in it's native format.

So, I can always work around Picospan - but it requires substantially
more difficult programming and significant cost in efficiency.

response 62 of 112:

Oct 19 16:52 UTC 2004

Re #60:  Performance issues aside, generating the RSS feed dynamically
by a CGI (or PHP, some sites do that) might be the better strategy.
That way you don't have to build an RSS "hook" into every piece of
code that affects item status (responding, scribbling, retiring, etc.)

response 64 of 112:

Oct 19 17:26 UTC 2004

I'd say no.  You'll notice that for every work-around Jan came up 
with, there was the issue of "complexity" or "significant time" it'd 
take to do these tasks.  And again, history shows that maintaining 
compatibility with older softwere only drags things down.  Apple 
realized this and only now is Microsloth catching on.

response 66 of 112:

Oct 19 18:06 UTC 2004

What of MH?

response 68 of 112:

Oct 20 00:24 UTC 2004

Regarding #59; For the record, OpenBSD *does* support the kqueue mechanism,
which allows a process to monitor events such as you describe.

response 70 of 112:

Oct 20 15:02 UTC 2004

Thanks.  I had glanced at the manpage for kqueue() but wasn't sure if
it could monitor such things as file status changes.

response 72 of 112:

Oct 22 13:54 UTC 2004

I have no idea of the status of ft on M-Net.  At this point, thanks to various
helpful users, I have a decent sized list of bugs to fix in Fronttalk.  But
right now I am not working on things that I don't think are important to
getting nextGrex up.  With Picospan installed, Fronttalk ceases to be on that
list.  I'll be returning to work on Fronttalk after nextGrex is up.

I think if I used kqueue(), I'd have to set up an event filter on every sum
file on the system.  It might be better than polling them, but it still isn't
great.  At least it is probably unnecessary to monitor every item file on the
system.  There isn't that much that Picospan does to an item that doesn't
also result in a modification of the sum file.

mfp is right again.  NMH version 1.0.4 is installing as I type.  There, it's
done.

response 74 of 112:

Oct 22 18:19 UTC 2004

An open source version of MH.