Re: White Pine CUSeeMe Version 3.1.1]

Jason Williams (streak@ccwf.cc.utexas.edu)
Fri, 17 Apr 1998 00:55:38 -0500 (CDT)


On Thu, 16 Apr 1998, Wayne Fisher wrote:
> I find it disturbing that so many people on the list question White Pine's
> decision to support their own versions of reflector software (2.x and the
> new MPCS software) over the myriad versions of reflector software out
> there. Let me digress for a moment....

Why is it disturbing? Backwards compatibility should be an important part
of EVERY updated piece of software. You should test it on the software
and hardware that you expect your market to be using. And there's the
key! White Pine's market is NOT the Cornell/Enhanced Reflector market or
one in which Cornell/WP 2.X clients co-exist with 3.X clients. And that's
where all the problems seem to be arising.

I have no problem with White Pine optimizing their client for use on MPCS
servers and their 2.1 reflector. What I do have a problem with is when
they BREAK compatibility with older clients and don't seem to think much
of it. I can agree that optimizing the client for their versions of
reflectors makes sense. But does that also mean they should develop their
own independent protocols that work solely on MPCS servers and nowhere
else? If you do that, then why have the name CU-SeeMe at all? That's
kind of like saying "there are two versions of Win95..one version runs one
set of applications while the other version runs another and they can't
cooperate".

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
service to the CU community trying to fix a lot of the White Pine client
bugs). Again, it comes down to White Pine's market. Are they concerned
with their client not working on anything but their reflector/server? I
believe so else the bugs in 3.1.0.25 wouldn't be addressed. They may not
be completely fixed in 3.1.1 yet, but they are trying at least.

> In todays business world, most software company's limit the systems,
> peripherals, and operating systems which will support their software.

I agree...but as a counter example, look at Microsoft. What would happen if
Win95 didn't run ANY Win3.1 or MS-DOS applications? How about if Win98
didn't run any Win95 applications? The key is to be backwards compatible
to a point. I can understand Win95 not supporting 8-bit code since the XT
hasn't been around for years. ie: the XT is clearly the minority with
very few people still using them. With White Pine, the MPCS server IS in
the minority as well while the Enhanced Reflector is gaining popularity.
Do you ignore that market and refuse to have support for the reflector in
your client?

> Let me use the Cornell CUSeeMe client as an example. In the release
> notes, the types of cameras which are supported by the Cornell version
> of the software are clearly outlined.

Actually, in the release notes it states:
"If your capture card is not listed above, but does support one of the
above video formats, it will likely work."

So the list that's there isn't a definitive list. I believe White Pine
has a similar list for the cards it supports.

> Let's pretend for a moment that I choose to purchase
> a digital camera that is NOT on the supported hardware list (for whatever
> reason). Would that then give me the right to complain that the software
> does not work (let me quote here.... "IMHO, software should work, period")
> because I chose to use something that is clearly not supported, or is not
> supported well?

So what you're saying is..it's ok for a software to distribute bugs with
its software as long as the limitations and bugs are clearly states in the
documentation?

And to be fair, the Cornell supported hardware list what capture devices
have been tested and work, not which devices DON'T work. There's also a
difference between free software and commercial software. Commercial
software is out there to support a company and allow it to grow and be
profitable. It makes much more sense in that case to support as many
devices, clients, and reflectors as possible in order to broaden the
base of potential buyers of the product. With a freeware product, the
authors generally aren't being paid to distribute free software.

> White Pine knows the ins and outs of their server software (i.e., Reflector
> 2.x and MPCS), so wouldn't it make sense for them to limit support for
> their client software (CUSeeMe 2.x and 3.x)? Tech support can only do so
> much....

It's not so much about support as it is backwards compatibility. The
support argument falls apart when ALL the White Pine versions for the last
2 years have been backwards compatible with the Cornell reflector and
client. White Pine could easily allow their client to work with other
reflectors without having to handle tech support for other reflectors. I
haven't heard of any cases where Enhanced Reflector or Cornell reflector
operators have bombarded White Pine with questions on how to setup their
reflector.

> Besides, there is a large number of video conferencing software packages
> available today which use proprietary server software to connect users. If
> one were to look at iVisit, VocalTec Internet Phone, ICUII, and VDOPhone,
> one would see that of these software applications work best when using the
> propietary server software to connect to other users. Why should White
> Pine be any different? I don't hear anyone complaining about these
> company's limiting the server software which can be supported by their
> clients.

No one complains about those companies because they don't have to worry
about backwards compatibility with people using OTHER software to access
their directory servers or other user's vid/audio/etc. So the only way
you are going to be able to see Internet Phone users is by using
VocalTec's Internet Phone application. There's no third party software
that's well established (as Cornell is) that allows you to see Internet
Phone users. With CU-SeeMe, there's White Pine and Cornell. Since the
Cornell version isn't really being developed anymore, all White Pine has
to do is ensure that their software is backward compatible to keep people
happy (since a large percentage of people DON'T use White Pine's version).

An interesting aside to this is H.323 compatibility. If you were so
deeply concerned about White Pine's tech support consider H.323 and having
the ability of OTHER clients not made by White Pine OR Cornell to connect
with MPCS servers. Just imagine the nightmare tech support is having
now...supporting Intel's Videophone, Netmeeting, etc. The ironic thing
is, when White Pine's "MeetingPoint Commons" was setup, there was minimal
tech support on getting the other H.323 clients connected ok.

And I'm sure you'd hear a LOT of complaining if someone like Microsoft put
out an update to Netmeeting which allowed you to ONLY conference with
other Netmeeting users using the same version as you and then also charged
you money for it. I doubt it would be very popular in the positive sense.
That's the whole idea for H.323: interoperability. Which means backwards
compatibility has to be supported as well.

> Please try to remember these comments (strictly my own opinions) the next
> time you want to bash White Pine for making a technical decision on what
> works best for software which they developed.

Thanks for the comments...<joke>And I wouldn't bash them if they did
things correctly </joke> :)

It may be a moot point since from the readme, it states that the problem
is still being worked on. White Pine hasn't publicly stated: "Our client
will now only function with other White Pine clients and reflectors. End
of story". So I have faith :)

--
streak@ccwf.cc.utexas.edu    * Jason Williams -- Austin, Tx.  |     |
streak@mail.utexas.edu       * University of Texas at Austin  | ___ |
streak@cs.utexas.edu         * BS Computer Science             \_|_/
*************** http://ccwf.cc.utexas.edu/~streak/ **************|