Re: Feature removal proposal

On Thu, Apr 15, 2004 at 10:26:54AM +0200, Attila Konietzka wrote:
> Hello Soren,
> Thanks for your request regarding these Features, so let me commend on what
> i think.
> >
> > * "Show your face" graphics.  This comprises a complicated part of
> > both the source code, and also the transmission protocol.  It is known
> > to contain some problems, and I don't think any of the current
> > developers know how it works.
> 
> Well I think it's not something that should remain in speak-freely because i
> would rather implement some file transmission feature, and if someone asks
> me what i look like, i can send him my jpeg-foto or do this image-exchange
> totally via E-Mail.

It could be replaced by an option to locally associate a picture with
a remote connection, as that would overcome the security issues of
accepting untrusted image files.  That would need someone keener than
I to get it done though.  My feeling is that unless someone steps up
to learn the image transmission protocol and do an audit of the code,
then the face feature will disappear from the next release.

> >
> > * Simple 2x compression (4kHz sampling).  This is a special-case
> > "compression mode" because it can be used in conjunction with other
> > modes.  With the modern codecs and faster CPUs, I don't see this being
> > useful anymore and it complicates the decoding process.
> >
> 
> Well i had my bad experiences with this mode of compression, because lpc and
> lpc10 as well as celp don't like this way of extra-compression, also the
> speex codec integrated for testing purposes by john h. would crash the whole
> program when used with simple compression, and afterall the speex codec
> works also with 133 mhz pentium cpus as i was once running a teamspeak
> server who would force the speex 9,1 Kbit/s codec upon anyone conecting to
> my server, this only in case anyone here knows how teamspeak works.
> 

Really, none of the modern codecs will work properly with it, because
they are tuned to 8kHz sampling.  Even without the coding issues, it
may be worth dropping for the sake of usability.  One codec at a time
is enough for many users to worry about.

> > * VAT protocol.  This was made obsolete by RTP many years ago. Does
> > anyone still use it?  Protocol detection is one of the more awkward
> > areas, so reducing the options from 3 to 2 may help.
> 
> I agree, since vat is somehow outdated, and most programs use rather rtp for
> this kind of communication i would agree on removing this protocol,
> especially because it can't handle the whole crypto-stuff alltogether.
> >
> > * direct modem communications.  With the ubiquity of the internet, is
> > this still likely to be of use?
> >
> 
> PLEAAAASEEEEE don't remove it!!!! Because it is somehow necessary still in
> some poorer countries in the world to exchange freely his communications so
> that the opressors wouldn't hount you, for they had tapped your line and can
> use anything what you said against you.
> By the way, does this still work in 7.6a? i didn't find the modem connection
> box, this was only something i found in the old 16bit versions of
> speak-freely, in their options dialog so how does this work in 7.6a?
> 

Ah, this is the type of response I was after.  The modem stuff is in
the codebase, but it is all within #ifdef MODEM constructs.  It's
possible that it simply wasn't enabled in 7.6a, or there could be a
problem with it.  I've never looked at how it works myself, and just
seen it in the code.  So far it hasn't got in my way, but I'm aware
that it will be difficult to test and debug any modem handling issues
after the code clean-up.  It would be good to hear from anyone who
uses this feature so we can make sure it stays working if it is
valuable. 

> > * Old version compatibility.  Is there anyone who would have problems
> > if the next version released were not compatible with some versions of
> > speakfreely prior to 7.6?   I think good backward compatibility will
> > remain regardless, but it would be good to hear any constraints on
> > this.
> >
> Well with the removal of some protocols and the removal of show-your-face
> feature some of the compatibility will be lost to the versions which still
> have this feature, but what do you mean besides this? Is there still for
> example some connection-initialization bloat or more than one hand-shaking
> routine that's coming with speak-freely, that needs to be run all through
> sequencially in order for speak-freely to connect to all it's predecessors?
> Any hint on what you specially mean would be appreciated.
> Thanks, and keep up your good work all of you Developers.
> 

The issue here is that if we weren't concerned about
backward-compatibility, then we'd redesign the speakfreely protocol.
It's valuable to retain interoperability though, but my question is
how far back should this go?  Things like face removal won't stop
compatibility for all the other features, but there are some more
subtle issues.  In parts of the code there are hacks to workaround
bugs in earlier versions, which are by now many years in the
past. It's probably time to start removing some of those hacks, and
force an upgrade on any person who is happening to still use the
really old version and wants to talk to someone with a new version. 

It's mainly to ask is there anyone who knows they cannot upgrade to at
least version 7.6a for some reason - and if so, what that reason is.
It could be because it stopped working on some particular platform
after version x.y.  It's not that we are likely to break compatibility
with older versions, but more if there are any specific issues to have
in mind.



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click