1
0
mirror of https://gitlab.xiph.org/xiph/icecast-server.git synced 2024-12-04 14:46:30 -05:00

Added a changelog (via svn2cl) and updated NEWS....

svn path=/icecast/trunk/icecast/; revision=8127
This commit is contained in:
oddsock 2004-10-28 16:11:10 +00:00
parent b2717b7ae2
commit e65325c5a9
4 changed files with 2436 additions and 49 deletions

2395
ChangeLog Normal file

File diff suppressed because it is too large Load Diff

47
HACKING
View File

@ -1,48 +1,5 @@
Note that these instructions are *not* necessary for distribution
tarballs; they have separate configure/build instructions.
Building this package from CVS is mainly intended for developers.
General users should obtain official distribution packages; both
source and binary distributions are available at
http://www.icecast.org/
-----
These are *brief* instructions on how to build this package from CVS.
Yes, there are details left out.
There are generally four steps necessary when building from CVS (i.e.,
a developer's copy):
1. cvs checkout of the sources, or cvs update. RTFM from your
favorite flavor of CVS documentation; information on the xiph.org
CVS repository can be found at http://www.xiph.org/cvs.html.
2. [re-]generate files such as "configure" and "Makefile.in" with the
GNU autoconf/automake tools. Run the "autogen.sh" script to
perform this step.
*** IF YOU ARE NOT BUILDING WITH GNU MAKE *AND* GCC: you must set
the AUTOMAKE_FLAGS environment variable to "--include-deps"
before running autogen.sh. For example:
csh% setenv AUTOMAKE_FLAGS --include-deps
csh% ./autogen.sh
or
sh% AUTOMAKE_FLAGS=--include-deps ./autogen.sh
3. Run configure. There are several options available; see
"./configure --help" for more information.
4. Run "make" to build the source.
In general, steps 2 and 3 need to be re-run every time any of the
following files are modified (either manually or by a cvs update):
configure.in
acinclude.m4
Running "make clean" after running steps 2 and 3 is generally also
advisable before running step 4. It isn't *always* necessary, but
unless you understand the workings of autoconf/automake, it's safest
to just do it.
Please visit http://www.icecast.org/svn.php for more detailed
instructions about building from Subversion.

39
NEWS
View File

@ -1,3 +1,42 @@
Icecast 2.1
-----------------------------------------------------------------------------
****New features for 2.1 (in no particular order):****
-Listener Authentication-
Icecast now supports listener authentication. This provides a mechanism for
creating/maintaining users and passwords for listeners. Currently, we only
have implemented a simple, file-based storage for users and passwords. New
authenticators are on the horizon (such as URL-based or possibly MySQL based)
New admin pages were also added for the maintenance of users/passwords. Please
check the docs for a more detailed description of this new feature.
-Multi-Level Fallbacks-
-Burst-On-Connect-
This is an new, optional config setting which will send a initial burst of
data to connecting listeners. This has the effect of reducing
(significantly) the startup buffer latency from the end-user perspective.
This option is enabled by default.
****New Enhancements for 2.1****
-Update to admin interface-
This interface has been cleaned up quite a bit and made a bit nicer.
-Rewrite of the YP listing code-
The icecast yp code has received a complete overhaul by karl, and it's a much
more stable and failure-resistant implementation.
-Lots and lots of bugs fixed-
Check the ChangeLog for a complete list of these...
-----------------------------------------------------------------------------
2003-10-12
Added documentation

4
TODO
View File

@ -25,15 +25,11 @@ FEATURES
- allow using get_predata() stuff to send an "intro" to any newly-connected
user?
- stats to list currently connected clients: ip and hostname
- general registerable url-handlers in connection.c rather than hard-coded list
(already getting unmaintainable)
- httpp - split out query string for further processing
- option to use ipv6 (equiv to using <bind-address>::</bindaddress>, I think.
- abstract all admin functionality to a set of commands, and command handlers.
Make /admin/* just parse according to a set of rules, and dispatch generic
commands through that.