[BusyBox] Hi all

[Tom Cameron]

Welcome back Erik,
	Howdy!  A few things about the "Changing the way help is
displayed" thread.  I began thinking about how much space the help text
takes up within the BB binary executable.  Then I began thinking of how
much space would be saved if the help weren't stored in the binary file,
but read from a text file elsewhere.  I would assume that the lines in
the C code that would be responsible for reading the data would add up
to less bytes than the data used up by the help text.  Made sense to me
at least.  Anyway, I then began thinking of how much easier it would
make it for developers of 3rd party applets.  I mean, all they would
have to do is add their text to the help file.  This brought on MANY
more ideas about how the applets should be integrated into BB (as I'm
sure you've noticed).  But if you really think about it, I believe this
would be a fairly decent change to BB.  I mean heck, you could even
compress the text file and....oh...oops...tangent...sorry.  ; )  Anyway,
I just wanted to clarify where this all came from for you.  Welcome
back.

--
Thomas Cameron
Network Technician / Operations Specialist
St. Mary's Bank

> -----Original Message-----
> From:	Erik Andersen [SMTP:andersen at lineo.com]
> Sent:	Wednesday, April 18, 2001 11:17 AM
> To:	BusyBox
> Subject:	[BusyBox] Hi all
> 
> Howdy.  First, my appologies for being a bit silent recently.  Towards
> the end
> of my trip to the Embedded Systems Conference my laptop died.  As in
> the BIOS
> wouldn't even post or anything.  So I took it to the IS dept on
> Monday.  They
> determined the MBR was broken.  So they formatted the hard drive and
> installed
> Win2K.  It has taken me till today to get my computer basically back
> to normal,
> though I did end up losing a bunch of things.  In the future, remind
> me to
> avoid the IS dept. <Grrrr>
> 
> Anyways, I have been looking over the "Changing the way help is
> displayed"
> thread.  I've started to put something together to try and address
> some of the
> concerns.  Basically I see several problems being discussed, but I
> think all
> the problems stem from a single fundamental issue, namely,
> 
>     It is currently hard to intergrate 3rd party/contrib/new applets
> 
> 
> The fundamental problem then is the mechanism for adding a new applet
> is not
> very patch friendly. To integrate a 3rd party/contrib/new applet
> requires the
> addition of the applet file itself, and requires editing of Config.h,
> usage.h,
> and applets.h.  But these files change often causing patch to
> frequently fail.
> Furthermore, some of these files have additional constraints (such as
> how
> applets.h must be sorted) which patch cannot guarantee will be
> satisfied.
> 
> The only sane and scalable way I can think of to address this is have
> each
> applet be a complete and standalone entity which is completely
> decoupled from
> busybox's internals.
> 
> For example, if each applet included its own APPLET("name", name_main,
> DIR) 
> stuff, we could basically grep for that stuff at compile time, sort
> it,
> and create the master applet list dynamically.
> 
>  -Erik
> 
> --
> Erik B. Andersen   email:  andersen at lineo.com
> --This message was written using 73% post-consumer electrons--
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox