Ok, I'll poke my two-cents in here for a minute.
One thing that should be considered is library dependencies. If we have
a library with two front-end executables, distributions that lack one or
the other can package only those executables that are relevant. By
packaging everything into one binary, it creates dependencies on all the
libraries for all the possible front-ends.
Further, the separation is explicit. If someone compiles ethereal
without GTK support, the GTK binary simply isn't there. If all possible
frontends were in one binary, we could end up with lots of different
variants of the Ethereal binary, all with different compile-time
frontends (based on the development libraries the packager had
installed).
Just a thought...
Devin
On Tue, 2002-09-17 at 16:22, Joerg Mayer wrote:
>
> On Tue, Sep 17, 2002 at 12:41:43PM -0700, Guy Harris wrote:
> > libm routines - and temporarily arrange that there's no
> > "/usr/lib/libm.so.2", and try to run the program, you get
> >
> > /usr/libexec/ld-elf.so.1: Shared object "libm.so.2" not found
> >
> > I suspect that's the behavior you'd get on most systems with a SunOS
> > 4.x-derived shared library mechanism, e.g. the BSDs, Linux
> > distributions, and Solaris and other SVR4-based systems. You might get
> > it with other UNIX systems as well.
>
> I don't think you are correct here: I've worked (well, acutally not :-)
> with versions of emacs that run with or without X. What I *think*
> they do is they load the required libx11 manually in case it is needed.
> Things could be done that way.
>
> On the original post: There are two ways to achieve better modularity:
> A generic application that loads the appropriate front end on demand or
> the other way round: Many specific front ends that load a set of common
> libraries.
> Both ways look interesting and both require a proper seperation of the
> dissector, wiretap and front end code first. Except for a patch recently
> sent dealing with files, there has been no work on that front for more
> than a year. So as long as nobody takes up the work, musing about which
> way is best is interesting but not improving Ethereal. That said: Once
> I'm done with the current automake mess I intend to open a new branch
> in cvs where I intend to make the dissector stuff into its own library.
> After that, the places that need cleaning up will show up more
> prominently :-)
>
> Ciao
> Jörg
>
> --
> Joerg Mayer <jmayer@xxxxxxxxx>
> I found out that "pro" means "instead of" (as in proconsul). Now I know
> what proactive means.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
