response 26 of 112:

Oct 14 23:15 UTC 2004

Yes.  Without it any answer you find will be unauthorized.

Marcus hasn't logged onto Grex for six weeks.  I don't know what his
status is, but I don't think we should be letting Next Grex wait for him
to do something.  Not that the general velocity of progress is so great
that there isn't plenty of time for him to jump in if he takes a mind to.

response 28 of 112:

Oct 16 13:29 UTC 2004

Cool.

That's not the decision I thought I'd been told about, but I'm fine
either way.

One mode in which Fronttalk has not been fully tested is when used as a
login shell.  I did a little testing with that configuration yesterday,
but not a whole lot.

response 30 of 112:

Oct 17 00:52 UTC 2004

I'll make the final decision:  We'll use Picospan on NeXtGreX.

response 32 of 112:

Oct 17 01:13 UTC 2004

Good to hear it.

response 34 of 112:

Oct 17 04:28 UTC 2004

It's because I said it should be!

response 36 of 112:

Oct 17 19:49 UTC 2004

The problem is that backtalk (and therefore fronttalk as well) must now
remain compatible with picospan.  Fronttalk is already a nearly 100% faithful
substitute from picospan; since we have that, why be constrained by the past?

response 38 of 112:

Oct 18 01:38 UTC 2004

Would it be boorish / stupid to create a member vote about whether or not to
break with picospan for NextGrex?  If not, if it's reasonable to consider
leaving picospan behind with oldgrex, then I'll create the vote item.

response 40 of 112:

Oct 18 05:01 UTC 2004

Here's what I see as the plus and minus.

If Picospan is installed on nextGrex, it will be the only piece of proprietary
software on the system.  We have complete source to everything else on the
system, and the legal right to modify it as we wish.

The only person who can see or modify the source code to Picospan is Marcus.
Picospan is not under active development.  I don't believe there has been
any change to it's functionality in over a decade.  Nor is there ever likely
to be.

Picospan is thoroughly tested and debugged.  There is some tiny chance that
some bugs will appear in the OpenBSD port, but I doubt it.

Fronttalk is open source.  In practice, the only person likely to be making
changes to it is me, but in theory anyone at all could do so.  The code is
all available on the web for anyone to download.  It is well documented with
both internal comments and separate documents.

Fronttalk does implement virtually everything that Picospan does.  Just
about every Picospan command you have heard of, and many you have not is
implemented by Fronttalk.  It reads the same .cfonce and .cfrc files.  If
you modified your iseps and rseps, they will work with Fronttalk.  Fronttalk
is a bit slower.  The difference is mostly only noticable during startup
on Grex, and should not be noticable at all on nextGrex.

Fronttalk has a rather strange architecture.  It actually consists of two
completely separate programs - a client that reads commands from the user
and formats output for display, and a server that manages the conference
data files and controls access to them.  The Fronttalk server is just
Backtalk.  Backtalk has been running on Grex for eight years, and hasn't
mangled a single item file yet.  This part of Fronttalk is well-tested and
dependable.  There is little chance that a bug in Fronttalk will result in
something catastrophic, like deleting all the item files or letting users
censor each other's posts.

The Fronttalk client is a perl program.  It has been running on Grex for
two years, but so far as I know, I am the only person who routinely uses
it.  It has never been heavily used by a large set of people.  I'm sure
it has bugs.  I even know of some that I haven't fixed yet (I've been
pretty busy with installing other stuff on nextGrex).  The "read since"
command doesn't seem to work right.  Prp recently reported a bug where
if you join a conference that changes it's command prompt and then join
another, the command prompt doesn't get reset right.  I'm sure there will
be other bugs similar to this.  You just don't find all these bugs until
you get a large set of users beating on it for a while.

So if we switch to Fronttalk, there will definitely be a teething period.
Bugs will be reported, and I will fix them in due course.

Part of what Fronttalk offers/threatens is the potential to evolve the
software.  If Picospan is kept, it will not change.  Backtalk and
Fronttalk might change, but the need to remain compatible with Picospan
will severely limit the kinds of changes that can be made to them.
Backtalk already contains some very complex pieces of code that would
be very simple if Picospan didn't exist.  The more I have to maintain
compatibility with Picospan, the slower continued development will be.
It also has a few features that are turned off here on Grex because
they would not be compatible with Picospan.  It is likely to develo
more.

For example, one of my ongoing Backtalk projects is teaching it to mail
out responses.  The idea is that a user could choose to have new posts
to selected items and/or conferences emailed to him.  You'd be able to
choose either to have a copy of each new response to an item mailed to
you immediately after it is posted, or you could have periodic digests
of the conference sent out to you.  (I do not plan to allow people to
post by sending email - instead each message would have a link back to
backtalk that you could click on to put you back in the item so you
can respond to it normally.)

Part of the coding for this has already been done.  Backtalk already
has a very nice mail sending system built in.  It can send either plain
text messages or mime messages with both HTML and plain text versions
of the same post.  The mode where copies of responses are sent instantly
when they are posted would be quite easy to finish off at this point -
I need to maintain a database for each item listing what users want
copies of responses sent, and everytime a new message is posted we just
send copies out to all users who want them.  Except this won't work
if Picospan is still being used.  Any message posted from Picospan
would not be sent out.  So instead I'd have to have a daemon process
running in background periodically scanning the sum files for all the
conferences to see when new messages have been posted, so it can
send them out.  Certainly this is doable, but it's much more complex.

Backtalk already has the capability to handle items and responses
with attachments.  That means you can attach any random kind of file
to any response - a text file, a Word document, an image, a sound file,
whatever.  Readers can see these by clicking on them.  I'm not at all
sure that this would be a desirable feature for Backtalk (the feature was
added for another organization that uses Backtalk).  At least I'd have
to finish implementing quotas that would limit how much data people could
post to the conferences.  This feature is not compatible with Picospan
because it requires changes to the format to the item files which Picospan
would choke on, and even if I found a way to keep the file format
compatible with Picospan (which certainly could be done at the cost of
some extra complexity) Picospan would not show the attachments.

These are just two examples that happen to already be mostly implemented.
Get rid of Picospan, and many things become possible.

This is, of course, not an unmitigated advantage.  Not all change is good.
It has to be done thoughtfully and carefully.  But some changes are certainly
good.  I think the email thing would be great for Grex.  It has several
advantages.  First, it would help us retain users.  Right now, a user can
get busy for a few months, forget all about his Grex account, and never
come back.  If that user has requested to be emailed new responses on
an item they entered, then their attention is going to get drawn back to
Grex each time someone responds.  Chances are good that they'll be sucked
back in again.  Second, it can restore life to dead conferences.  There are
many conferences on Grex that get responses less than once every month.
People stop checking in, even though they are interested in the topic
of the conference, just because there is never anything there.  So when
someone new comes in and makes a posting, nobody sees it for weeks.  The
new person wanders off, and the confernece remains dead.  But what if
that new post were emailed out to a bunch of people interested in the
topic?  They'd likely come streaming back, and that new post would trigger
a wave of activity.  A dead conference comes alive.

So the email feature is likely to improve Grex's ability to retain
conference users, and thus increase the conferencing population, and it
is likely to bring life to many old conferences, helping to reverse the
trend for everything to happen in the 'agora' conference.  Might even
improve Grex's income.

Or it might not.  I'm only guessing.  And I don't even know when I'll
have time to finish implementing it.  I do need to take time off now and
then to change little diapers and earn a living.

Picospan is a wonderful thing, but it is 20 years old and not going to
change.  It's an anchor.  Anchors are very useful at times.  But is
this such a time?

response 42 of 112:

Oct 18 05:39 UTC 2004

How about using both Fronttalk and Picospan for a while (a few months?) until
the bugs in Fronttalk are mostly caught?

response 44 of 112:

Oct 18 13:02 UTC 2004

Sindi's suggestion is fine, but note that we've been running both Fronttalk
and Picospan on Grex for two years.  I use regularly.  I'm using it now.
(Actually, I'm not logged onto Grex - I'm running the fronttalk client on
nextGrex to communicate with the fronttalk server on Grex.)  Not many other
users use it though, so I'm not getting many bug reports.  Recently prp
spent some time testing it and turned up some good bug reports.  I'll have
those fixed by the time we get NextGrex up.

I can live with Picospan continuing to be here.  I've been programming around
it for years and I can keep doing it.  But I do need to know what the plan
is going to be.  Once I get nextGrex off my lap, I hope to return to doing
Fronttalk/Backtalk development, and the strategies I use depend heavily on
whether I need to continue to maintain compatibility with Picospan.

response 46 of 112:

Oct 18 14:26 UTC 2004

How does one go about using FrontTalk right now, on the current grex?

response 48 of 112:

Oct 18 14:45 UTC 2004

At the moment, do picospan, fronttalk, & backtalk all manipulate the
conferencing files in the exact same way, such that there is total data
consistency?  If so, the real question is whether to bother to try out the
OpenBSD recompiled picospan on NextGrex or not.  If it's all ready to go,
then it need not be an either/or proposition.  However, if there is a good
possibility of bugs in OpenBSD-picospan, bugs that might not be fixable,
then that is one good reason not to bother with it.

Would a determination that picospan will not be used or supported on NextGrex
materially help get NextGrex launched and foster improved support?