package site information more dynamically updateable
ben at xemacs.org
Tue Oct 25 00:18:55 EDT 2005
Stephen J. Turnbull wrote:
>>>>>>"Ben" == Ben Wing <ben at xemacs.org> writes:
> Ben> yes, we should put xemacs-base into core.
>I disagree. That will just bite us later with shadows and
>backward-and-forward incompatibility. We'd be much better off
>defining reasonable interfaces where we can and moving that stuff
>_out_ of core, while providing a facility for installing minimal
>packages or SUMOs from the distribution tarball. Things like URL
>fetching etc are perfect candidates, since they're basically defined
moving core stuff out of core just introduces more and more dependencies
between core and packages. if we maintain the stuff anyway, and its
critical to the core, there's zero point in it being in the packages.
>On the other hand, our specific UI features are candidates for moving
>back into core (I'm thinking specifically of annotations and fields),
>if we can't standardize the APIs well enough to make them "public
>I know having stuff in packages is annoying to you, Ben, but I believe
>that the prospect of working with that big ball of mud we call "core"
>is a prohibitive deterrent to a lot of people who might otherwise
>contribute an occasional fix.
what's your evidence? has it stopped contributors to gnu emacs, where
there is even more in the core?
> Ben> yes, we should switch to an http package installation
> Ben> system. (really really really; http is *much* more reliable
> Ben> than ftp these days and works through firewalls consistently)
>This would be a lot easier on the users if package-get were itself in
why? it has to get implemented, either way. core or package won't make
much difference except that putting it in a package means someone has to
go to extra work to implement the "put the packages in the core
distribution" bit. will that be you?
More information about the XEmacs-Beta