Re: White Pine CUSeeMe Version 3.1.1

Scott Lacroix (
Tue, 21 Apr 1998 11:11:18 -0300

At 01:47 PM 4/20/98 -0600, Brian Godette wrote:
>Hmmm, not a bug... ok lets call it a missing feature, a feature that has
>been present in GeekTalk since it's first release and always in GeekPC (and
>the first piece of code I wrote called privchat that I handed off to Mark).
>In anycase it was a pre-existing method (aux Priv) with it's own set of
>rules such as putting <privately> on all private chat to clients that don't
>report supporting aux Priv, which is exactly what my ref does.

But GeekTalk does not define the protocol. The format for private chat
DATA is not in the protocol. In fact, NO format for ANY data is in the
protocol. Only headers and transport methods. But you know that.
My point is, no app is REQUIRED to implement anything that is not DEFINED
in the protocol. By building clients that REQUIRE features that are
optional at best (I never saw an RFC on this mailing list discussing
private chat implementations, but then I'm new here) then IMHO that client
is broken.

>>At 02:36 PM 4/16/98 -0400, David Toole wrote:
>Really? We are talking reflectors here and not client-to-client
>interoperability right? If we are talking reflectors, as I said from a
>client point of view there's only two.

And you're assuming that all future reflector implementations will be as
complete as yours & WhitePine's. I'm not that optimistic.

>> It's not a bug, it's just up to YOU to mark it.
>In my opinion it is a bug considering that private chat was not developed
>by WP. If you're going to support a third-party
>feature/protocol/technology, at least do it right.

Ok, as near as I can tell from the age of the code, private chat was set
down by Cornell in the origenal spec. It's not a question of who owns it.
It's a question of HOW you USE it. It seems that most clients are relying
on an optional marker (in the chat text) that's not part of the protocol.
It's put in by the sending client (automagically by the client software,
not the user).
If WhitePine (or the Linux client, or the O/S2 client, or whoever) fails
to implement an optional (not really defined) "feature", that's not a bug.
If everyone else is RELYING on that optional feature... well that just
can't be good. Perhaps it's time to update the protocol to include payload

>> And if people NEED to have the server do it FOR them, then the ERef has
>>that ability now. Personally, I'd rather just do it myself then have
>>anything else leading me along. Or for that matter, having the ERef stuff
>>something into a message I've already marked...
>It doesn't... it checks for <privately> first of course, did you think I'd
>only do half a job?????

Ah, and this is what I mean by "not really defined". Why did you chose
"<privately>"? What's wrong with "<whispers>" (which I believe is what IRC
uses for /priv messages)? Or for that matter, how about "[PRIVATELY]"? Or
"<for your eyes only>" or whatever I chose? So long as the reciever gets
the point. That's why these things NEED to be defined in the protocol, by
the GROUP, and set down in stone.
And no, I didn't. Like I said, you're very good at what you do.

>> BTW, I know the arguement that it makes it easier to tell if someone is
>>harrassing you with private chat... But most people can tell pretty quick
>>if they are the only ones getting obnoxious messages. And stuffing
>>"<privately>" in the chat won't stop people from sending it anyway...
>Thus... NO-GEEK and CONF-NO-GEEK, how nice :) and of course those settings
>don't apply to EGeek32 as it has a better way to handle it <wink> <wink>.

I forgot about those...
<privately>IMHO those should probably be in the MPCS as well... Shhh...

>>>There's also not a "myriad" of reflectors. As far as I know, the MAIN
>>>one used is Brian Godette's Enhanced Reflector (And Brian performs a great
>In terms of protocol used there's two, RTP with MPCS and Cornell with
>everything else, three types if you want to include the TCP setup in WP 2.*
>refs. As for the servey... just count up the numbers off of Streak's
>scanner, this of course is only a valid count of public (or near public)
>reflectors and disregards any installed MPCS/WP systems inside businesses.

Absolutely true. But people are talking as if Tech Support and QA time has
no bearing on product. That's just not true.

>As far as I know, to a client it's no different except that it does route
>color. All the expected protocol interaction is there. However support for
>a few things outside of what can be defined as a standard Cornell protocol
>client do exist in it, and have no relation to anything any existing client

Seriously, I expect there is no difference to the client (between the
Cornell refs and the ERef). That's what I meant by my (rather sarcastic)
comment, that people should just wait for the fix and the ERef should be fine.

And don't say that too loud... If Jason sees that you've added things that
are above & beyond the basic Cornell protocol he may start asking why YOU
are saying you're a CU-SeeMe Reflector!

- Scott


,-==================================-.-==================================-. | I haven't lost my mind, it's backed | Scott LaCroix ( | | up on tape around here somewhere... | Sr. Software Engineer ___ | | - Author Unknown | White Pine Software ./_ -\. | | #include<disclaimer/std.h> | q| o O |p | `-==================================-^-=====================oOOo=~U~=oOOo-'