Perhaps apps aren't REQUIRED to implement what's defined in the protocol,
but it makes good marketing sense for a company to do it if there's
already "standards" of doing it. This holds true especially when the
prospective user use the additional feature.
> 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.
It sounds like you're up for authoring an RFC on the CU-SeeMe protocol? I
have yet to see one (and MANY people have asked me for one).
> Perhaps it's time to update the protocol to include payload format(s).
By all means forge ahead :) Brian has mentioned to me some of the
improvements that can happen to make CU a better product. Perhaps you can
work with him on that (or maybe I'm delusional from lack of sleep) :)
> >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...
> :)
no comment <grin>
> <joke>
> 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!
> </joke>
Heheh...well hey.. I like the idea of inheritance in object oriented
languages :) It's sorta the same. :)
ok..ok.. Im going back to bed..hehe
-- 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/ **************|