response 25 of 105:

Oct 21 05:49 UTC 2004

i'm curious if anyone can explain how switching to fronttalk is in any way
likely to bolster the quality of bbs's content.

response 27 of 105:

Oct 21 06:38 UTC 2004

I think staff should organise a counter-strike move that goes against the
member's wishes.

response 29 of 105:

Oct 21 19:04 UTC 2004

I don't care if picospan is on the machine as long as it's *not* the
default, and as long as plans are in place to either (a) get it open
sourced (I can't believe that'd be terribly difficult at this point)
or (b) get rid of it.

Regarding #26; Marcus has been largely MIA on NextGrex work.  Despite
the fact that he's made major contributions in the past, his is not
the only voice that counts.  I object to the idea that we have to do
whatever Marcus says just because he wrote PicoSpan.

response 31 of 105:

Oct 21 20:44 UTC 2004

It's not going to happen.

response 33 of 105:

Oct 22 14:34 UTC 2004

I do feel it is best for Grex to transistion to Fronttalk, or another
non-proprietary picospan-like interface.  (No other non-proprietary
Picospan-like interfaces now exists, but it would certainly be possible
to build one.  Fronttalk's architecture is a bit weird.  With open-source
Backtalk code available for use as a reference or cannibalization, it wouldn't
actually be awfully hard to build an open-source picospan clone with a more
traditional architecture.)

However, given that Picospan arrived, I think it best to stick with it for
the time being.  All the major tasks for getting nextGrex have been done. 
All that's left is a few smaller tasks and some more testing and debugging.
Having Picospan on hand now means I don't have to put any time into Fronttalk
debugging.  This gets us to nextGrex faster, and ensures greater stability
in at least one essential piece of software.

After we are up on nextGrex, I'll fix everything on my current fronttalk
bug list, and I'll ask people to "take the fronttalk challenge" - alias
"bbs" to "ft" and see how it goes.  If I can get a decent population of
test users, we can get fronttalk a bit more stable and get it into a
state where nobody will regret the change when we do eventually drop
Picospan.

That's what I see right now as the ideal scenario.  Decouple the Picospan
question from the nextGrex project.  Get more people into Fronttalk to
test it out more thoroughly.  Don't switch until Fronttalk is ready.

response 35 of 105:

Oct 22 18:41 UTC 2004

#33, sounds logical enough.  This will give people a chance to compare 
the two programs, and then there could be a vote, using the !vote 
program, on which to use.

So when is the grand opening day for NextGrex going to be, 
theoretically, since you won't need immediate time to debug fronttalk>?

response 37 of 105:

Oct 22 20:30 UTC 2004

I hope not.  I too wish Picospan had not made it onto the new 
machine.  But I'm so greatful for what Jan has done to this point, 
and, quite frankly, amazed he has been able to dedicate the needed 
time, that I feel greedy asking for FrontTalk to be ready for prime 
time on NewGrex launch.

Whatever he can give us is more than we would have had.  A huge 
thanks, Jan.

response 39 of 105:

Oct 23 01:38 UTC 2004

I predict that it won't happen.  Once the machine is up, Picospan will
be ``good enough,'' and there won't be any incentive to replace it.
Yeah, sure we can do all this high speed stuff with the fronttalk/backtalk
combo, but we could have done that now, on the Sun4, and didn't.

response 41 of 105:

Oct 23 03:13 UTC 2004

I think Dan's prediction will not come true.  Yes, there is always reluctance
to change from a known piece of software to an unknown one.  I not only expect
resistance to change, but respect it.  However, I strongly believe that Grex's
conferencing software must evolve, and will continue to press for that.  I've
sold bigger changes than this to the Grex users, and I can do it again.

I would never simply go out and replace Picospan with Fronttalk.  I would
always discuss it first, listen to reactions, see what I can do to
accomodate people.  Heck, that's 90% of what Fronttalk is.  I didn't really
have a burning desire to write a clone of a 1980's conferencing system -
I'd much rather be designing a conferencing system for the 21st century.
But I recognize that people want to keep their familiar interfaces. 
Fronttalk has the potential of preserving the familiar interface while
enabling new development.  It's all about keeping people who like Picospan
happy, and if it doesn't do that, then it needs fixing, and I'll fix it.

(The other 10% of the reason for writing Fronttalk was the fun of the
design - hiding a client/server architecture under the skin of a old
monolithic program, transmitting Backtalk into a server for something
other than web-browsers, and even the way rseps and iseps are handled by
translating them into Perl functions at load time and just calling the
functions each time we need to print them.  I couldn't get into cloning
Picospan until I thought of a way to make it semi-cool under the hood.)

If it comes to a vote, I'm OK with that.  But I don't want to switch to
Fronttalk just because a majority want it.  I'd really like to get it
to a state where virtually nobody really objects to it.

response 43 of 105:

Oct 23 03:55 UTC 2004

Since we are going to be re-building the new grex machine at regular
intervals, it seems likely to me that at one of those rebuilds, in the not
too distant future, we'll simply eliminate picospan.  By that time, it's
possible that almost everyone will already have migrated to fronttalk.  One
way to facilitate that migration is to configure newuser to default to ft
instead of bbs.  Or maybe for everyone, by adding an alias to the system-wide
cshrc file (as, I think, has already been suggested).

response 45 of 105:

Oct 23 04:38 UTC 2004

Yes: It avoids the telnet queue.

response 47 of 105:

Oct 23 05:21 UTC 2004

Why would anyone want to be on Grex if they aren't running BBS in text mode
with a terminal?

response 49 of 105:

Oct 23 14:24 UTC 2004

Re: #47
        Tod, of course it's 'party' - run in text-mode monitor
        (which should be amber or green).

        Hmm, or lynx? or pine? - nah, it must be party.