Web Server Patch

[Till Straumann]

Ralf Corsepius wrote:
> Am Fre, 2003-04-11 um 00.26 schrieb Joel Sherrill:
> 
>>Till Straumann wrote:
>>
>>>Hi all.
>>>
>>>I'm still very much at unease with the fact that this goes
>>>into the RTEMS source tree.
>>
>>In particular, I don't like the webserver being in the tree
>>but since we don't have a model for constructing RTEMS add
>>on packages that contain their own configurery, it is the
>>best place to ensure that it is maintained and gets built 
>>on a regular basis.
>>
>>
>>>Don't misunderstand me - I think it's great if a webserver
>>>is ported to RTEMS. I just don't think it should be part
>>>of RTEMS proper but unbundled.
>>>
>>>A web server, telnetd, shell, pppd are IMHO _applications_
>>>and I can't see a good reason why they should reside in
>>>librtemsbsp.
>>>
>>>Please consider making each of these applications a separate
>>>library, at least.
>>
> Why? Where are the benefits? I don't see any.

For one: I'm sure I only get what I want. Remember the
name clash issue with pppd? It took me two days of valuable
time to detect that there was a clash, that it was due
to pppd, dig through the automake magic to find out how
to eliminate pppd, report and discuss everything etc.

Don't underestimate the name clash issue. The more those
libraries grow the chances increase.

All of that mess for dealing with an application I don't
even use. I devote a LOT of time to developing and testing
RTEMS + my own applications. I can't deal with yet other
applications.

Also, while it's nice that there is a 'shell' and a 'tftpd',
you should leave the user the freedom to use a different
implementation. Having your global namespace already
cluttered with similar symbols doesn't help avoiding problems.

A second reason: [without referring to any package in particular
and having said this already in previous postings] For sake
of OAR's reputation. IMHO, there are huge differences in
readability and quality of RTEMS core and some of the contributed
packages. By throwing everything together users are more likely
to lose confidence in RTEMS quality when what they really have
are actually problems due to third party stuff. If a package
has the "OAR inside" sticker, I know I can use it. If it does
not, I have to look under the hood...

A third reason: We are working with a generic RTEMS system
and run-time loading [once you checked this out you'll see
how nice it is!]. It is much easier to configure that
system (i.e. decide what should go into it) when you compose
it from several pieces than having to sort out unwanted things
from a huge library.

-- Till

> 
> Ralf
> 
>