Re: White Pine CUSeeMe Version 3.1.1

Scott Lacroix (slacroix@wpine.com)
Tue, 21 Apr 1998 10:24:38 -0300


At 07:22 PM 4/18/98 -0500, Jason Williams wrote:
>Thanks for the detailed response...and quite helpful as well :)
>So 3.1.1.004 is still a preview/beta? :)

Hey, anything for you! :)
Yep it is... stay tuned....

>I'd gladly point it out, except for the fact that it's still buggy too
>from what I can tell. I loaded up 3.1.1.004 in grayscale and connected to
>my MPCS server. People got the first frame, but no movement at all.
>Granted, I didn't test it out for hours and on multiple reflectors, etc.
>If I was officially beta testing it for White Pine, I probably would. But
>as it stands, I can hardly stand the interface as it is :)

Well, that just can't be good! ;)
There's at least one other thing that could cause that, happens to me all
the time. And it has to do with the capture card drivers. I'd know more if
you did multiple tests & had some more results, but hey... it's not a
terribly big deal. And here's a question, if you're not Beta Testing, and
you hate the interface, why DO you run the 3.X client at all? Why not just
delete it & not worry about it anymore?

>So it's a "feature"? Hehe..
>From the Enhanced CU 2.X user's point of view, it's a bug. As far as I
>know, GeekTalk, private chat on the Cornell 0.92b2 version, GeekPC, etc.
>all tag the private chat. So this "feature" only appears in the 3.X
>versions and I have yet to see anyone thank White Pine for including it.
>Perhaps there's a reason for this.

Hmmm.... perhaps it was an oversight in the 2.X client that it failed to
mark incoming private chat... and thus a bug in all other clients that they
EXPECT the SENDER of private chat to flag it for them. Send priv chat to a
3.X client from a Cornell client (et al) and it should flag it, REGARDLESS
of whether or not the sender marks it.
And I THINK the 2.X client came out before GeekTalk, right? Since there
weren't any clients sending private chat, it wasn't a big issue at the
time. So you can see how it may have been easy for an oversight like that
to creep in.
So it depends on how you look at it... Personally, I see it as a design
flaw in the reciever. They are RELYING on the sender to ALWAYS mark private
chat. That means that EVERY potential CU client developer has to be aware
that ALL private chat MUST be flagged or the reciever's client won't know
to mark it. AND that all INCOMING private chat WILL PROBABLY be flagged
already, so marking it is redundant. Unless someone didn't get the message
that there had been a protocol change and that private chat now requires a
marker in the text.
Personally, I'd rather just have fixed it in the reciever.

>> What Brian did is to modify every private chat packet outgoing to an older
>> client. I'm glad he took it apon himself to do that, it's a big help to
>> some people.
>
>"Some people" include those that use the older White Pine clients. You're
>only punishing your PREVIOUS customers this way. Every other version of
>CU-SeeMe that I know of correctly sends and displays private chat.

They correctly display private chat if and only if the SENDER marked it.
If a 3.X client sends private chat to a Cornell client, does it display as
private? And if they send it to an OLDER Cornell client, does it display as
private? Is that a bug in the sender or reciever? Personally, I still think
it's the reciever. But I'm paranoid and I NEVER rely on the anyone else
knowing what my protocol changes are. Never mind every potential future CU
delevloper.

And keep in mind that you're talking about this as if it were a protocol
problem. It's not. It's a stylistic thing that GeekTalk introduced and
other clients/programs picked up. If it's not defined in the protocol as
required, you CANNOT rely on it.

>I suppose this could be a tactic to try and force people to upgrade to
>3.X. "As an added incentive, you'll be able to distinguish public chat
>from private chat".

I suppose we could run down the Conspiracy Theory again. But I thought
we'd outgrown that.

>> Just a random thought on that one... It seems to me you guys do some
>> incredibly detailed testing/debugging... I don't suppose you ever
>> considered mailing your tests and/or results to WhitePine to get a fix?
>
>Ahh, but that email I got from Brian was CC'd to me. It was also sent to
>your fellow co-worker Gary Dietz back on January 7th, 1998.

Ok, I'm not sure what kind of bugs you guys have reported in the past and
what kind of problems there are.... but it seems that if (reletively new)
people like me are going to rant about bug reports, we should be a bit more
solid on the existing problems in the Tech Support system.
I promise, I'll check into it before yelling about it again. Mind you,
that doesn't mean I'll just stop yelling :)

>> Since it's obvious that you are very concerned with the quality of our
>> software (and I think that's great), why don't you send the data to the
>> beta-test program rather than blasting WhitePine in a public mailing list?
>
>I've attempted to send bug reports to the MPCS beta-test list but was
>told by [QA/TechSupport For MPCS Beta] that the beta-test list was for
White Pine
>internal list use only. As far as client bugs, I submitted a few :)

I think you're off here somewhere. There DEFINATELY is a bug-report
mechanism for the MPCS Beta users. If they said "dont use the list" then
that means there's another method. And I think you got an email re: that
anyway...

>I know Brian has told me that he's tried sending bug reports to White Pine
>as well but never hears back from anyone. In one case, the bug fix was
>one line of code.

He did, he sent it to me. But like I said, I lost the thread. As I
remember it, that one line was a functional change, and in a corporation
you can't make functional changes just 'cuz they're easy or you think
they're right. You have to go through the development cycle.
So, resend me the email & I'll try & get it in. At any rate, you'll
definately get a response... :)

>> Actually, there are four as I see it. The base Cornell reflectors, the
>> WhitePine 2.X reflectors, the ERef, and the MPCS. And I don't know WHAT the
>> MAIN one is, but I'd LOVE to see a survey! How bout a show of hands...
>> Everyone that runs a ref that's reading this list: What type/version of
>> reflector/server do you use?
>> This should be interesting, eh? :)
>
>My reflector scanner keeps track of versions of reflectors. It can
>distinguish between Cornell, Eref, WP 2.0, WP 2.1, and 3.0 (MPCS)
>reflectors/servers.
>The stats, ranked in decreasing order:
>WP 2.X reflectors: 96
>Enhanced Reflectors: 61
>Cornell reflectors: 48
>MPCS servers: 26
>------------------------
>Total: 231
>
>So the two most "numerous" reflectors are the White Pine 2.X and the
>Enhanced Reflector.

And, that make the WhitePine 2.X reflector the MAIN! Wheee!
Ok, got that off my chest! :)
I don't doubt that the ERef popularity is growing rapidly. It may even
outshadow the 2.X ref evenually (in the market that you're surveying). But
even still, the MPCS already has over 10% market share and it's only been
out a few months! Not too shabby, you gotta admit!

>> Hmmm... that's not entirely accruate either. Those are certainly the two
>> biggies, but there is an OS/2 client, an Amiga client, a Java client, and a
>> Linux client that are all developed independantly.
>
>I was referring to the "official" versions...distributed by White Pine and
>Cornell. I also regularly use the Linux client so I see your point.

I know you were. Official or not, you can't rule others out when talking
about tech support. Just 'cuz they're not popular and/or you don't use
them, that doesn't mean tech support doesn't have to deal with them.

>> An excellent point, lets add them in too...
>> Now, tell me again how simple it would be to keep support for all four
>> existing server implementations? :)
>
>Not hard at all since the code for backwards compatibility presumably
>stays the same. The Cornell protocol certainly doesn't change. And
>considering the White Pine and Cornell clients are the "official" sources
>of CU-SeeMe, it would be up to the other clients to comply to the
>standards.

TECH SUPPORT! Not ENGINEERING! They don't care about code, just volume of
calls! The more things you add to the comatability matrix, the higher the
call volume, the more time/resources needed. The same applies to the QA
team, BTW.
It wasn't dropped because we thought it was to hard to implement from a
techinal viewpont, rather that it's too time & resource consuming to
support the ERef and everything that comes after it from a corporate
viewpoint. The line in the sand has to be drawn somewhere.

>>
>> Mmmhmmm. To my knowledge, you cannot connect NetMeeting 2.0 clients to
>> NetMeeting 2.1 clients... but I'm not SURE about that. They certainly will
>> work ALOT better if you use the same version numbers!
>
>I agree..and considering MS doesn't charge for an upgrade to 2.1 (as White
>Pine charges for its upgrade from 2.1) then it's a moot point.

Thus, if the next rev of the Cornell client didn't support backwards
compatability with older Cornell clients, that would also be a moot point
(since they don't charge either)? Don't flip-flop here, we're talking
apples and apples.

>> Mmmm... and as stated above, there are FOUR versions of the
>> reflector/server from the Tech Support point of view.
>
>From tech support, perhaps. But I believe from the technical viewpoint,
>there's the Cornell/WP 2.X flavor of connections and protocols. Then
>there's MPCS's RTP handling for the 3.X client.

Yup, you're absolutely right. And like I said in the bit you clipped out:
"If (as Brian says above) there are no differences between the ERef and the
basic Cornell refs (as far as the client is concerned), then there is
nothing to worry about (as far as the ERef is concerned)."

>> Just my (very vocal) $0.02...
>
>Again, thanks for your input :)

Hey, ya know... anything for you! Just trying to brighten your day!
:)

- Scott

--

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