[Mono-devel-list] Idea: Bittorrent and Mono.
mstanley at cauldronsolutions.com
Mon Jul 26 10:46:23 EDT 2004
On Fri, 2004-07-23 at 15:41, Dave Mertens wrote:
> > >How interesting a BitTorrent client may seem. It doesn't belong in the
> > >mono branch (Same with Mono.Posix en Mono.GetOptions).
> > >These days I see more and more additions which build upon Mono.
> > >
> > >I think it would be wise to create a PEAR alike repository where classes
> > >can
> > >be developed which are not directly needed by the runtime. When a class
> > >become very populaire, maybe than there's an option to distribute the
> > >with the main Mono (or MCS) distribution.
> > Just to clarify things, mbas (the MonoBASIC/VB.NET compiler) does require
> > Mono.GetOptions, so as the compiler is going into the core (thousands of
> > ASP.NET developers eager to use mono program in VB.NET exclusively),
> > Mono.GetOptions will probably go with the core. Besides, many other Mono
> > utilities does use Mono.GetOptions.
> > Mono.Posix is required for xsp/mod_mono, so again it's will be a pretty
> > common requirement. Still, last time I saw, such assemblies where being
> > packaged in a separate package, for those that want just a minimal C#-only
> > development environment.
> Well, currently I see Mono growing really fast. But Before you know it, it a
> complete OS..
> First, there's mono. Mono is the runtime to run CLR-code. In my opinion this
> package should be as limited as possible (meaning no compilers!). We have a
> few mono projects in the pipeline, but compilers (for whatever language) for
> forbidden on production servers for obvisous security reasons. The MS
> runtime doesn't provide compilers (the SDK does)..
> I see MCS as the SDK. So MCS should provide the mcs and vbas compilers and
> some optional namespaces)
> MCS is the SDK package for Mono. But MCS gets heavier with every release.
> I'm a development manager and also responsible for deployment of my
> projects. Security is these days a very hot issue. Everything that is not
> needed but is installed is a potentional security risk.
> Currently mono doesn't come with the posibilty of disable certain
> namespaces. I don't need Mono.Data.MySQL or Mono.Npgsql if I'm using SQL
> Server or oracle. The split up of Mono and MCS it a very good thing. Having
> tools such as mcs, mbas, nant, nunit on production servers are a hackers
> paradise.. ;-)
> I'm not saying that I'm almighty or it has to be my way, but I think I would
> be wise not to make each namespace part of the main distribution because a
> program *might* use it. As nant comes with mcs a solution could be:
> - Make a nant task 'dependency' with an download url (maybe from the
> mono-project website). If the dependency is not available on the (current)
> system, nant could download the package, build it (using a build script for
> that package, which could have dependencies on his own)) and installs it.
> A tool for managing the packages would also be handy. A side from that a
> also mentioned that common used namespaces could be inside the main
Isn't this the purpose of the GAC? One (*amazing*) advantage of .NET is
how they manage assembly dependencies, versions, and security. If you
are an administrator of a system that is using .NET you have fine
grained control over what is available and/or accessible.
> Just my two cents,
> Dave Mertens
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list