[Mono-devel-list] Idea: Bittorrent and Mono.

[A Rafael D Teixeira]

Hi Dave,

Just a correction,

Four compilers come with the .NET Runtime 1.1 (not SDK): csc (C#), vbc 
(VB.NET), vjc (J#) and jsc (JScript.NET). This is because ASP.NET depends on 
compiling pages on-the-fly. Indeed any program can invoke the compilers at 
anytime as there is specific classes in the System assembly (CodeCompiler 
family of classes) to do it easily. Call it a security risk, probably 
mitigated a bit by CAS already working on their implementation, but that is 
the way things currently behave.

So basically an ASP.NET 1.x server HAS to have the compilers deployed, 
PERIOD.

Indeed, I've read something about ASP.NET 2.0 being able to work with just 
precompiled pages, but that is counter-productive to the way most sites are 
currently developed/deployed and specially mantained. Call it a security 
risk, too, but currently is the mainstream way. Here some automated 
build-and-deploy tools (make files or nant buildfiles with some new tasks) 
could help to change that.

Best Regards,

Rafael "Monoman" Teixeira
Mono Hacker since 16 Jul 2001 - http://www.go-mono.org/
MonoBrasil Founding Member - Membro Fundador do MonoBrasil 
http://monobrasil.softwarelivre.org
English Blog: http://monoblog.blogspot.com/
Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/




>From: "Dave Mertens" <dmertens at zyprexia.com>
>Reply-To: <dmertens at zyprexia.com>
>To: "'A Rafael D Teixeira'" <rafaelteixeirabr at hotmail.com>,        
><jeffwilcox at gmail.com>, <mono-devel-list at lists.ximian.com>
>CC: <wilcoxj at umich.edu>
>Subject: RE: [Mono-devel-list] Idea: Bittorrent and Mono.
>Date: Fri, 23 Jul 2004 21:41:19 +0200
>
> > >How interesting a BitTorrent client may seem. It doesn't belong in the
>main
> > >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
>class
> > >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
>distributions..
>
>Just my two cents,
>Dave Mertens
>

_________________________________________________________________
MSN Messenger: instale grátis e converse com seus amigos. 
http://messenger.msn.com.br