[Mono-list] Web Forms, Apache module mod_asp.net?

[Sam Ruby]

Jay Freeman wrote:
>
> Actually, that is what I meant.  When I said "work closely with Costin on
> Jakarta" I didn't mean actually be _part_ of Jakarta :-).  The idea is
that
> if there were two engines (as opposed to a single one that worked on both
> platform), it would be a shame if they diverged much.  I have done
research
> in the past about approaching Apache with a project such as this, but
> noticed the requirement that there be two groups of people interested in
it
> (rather than the one person I was at the time).

Normally, the requirement is three, but that shouldn't be much of a
problem, particularly if you are still interested and Costin can be
recruited.  I would enjoy the opportunity to work with Costin again.

> About your second point, I agree with that (and have stated so in the
past:
> http://lists.saurik.net/message.xsp?id=62 , Phase 3; I also go into a few
> more of the similarities).  With a Java compiler for .NET it could likely
be
> done quite easily with the same core but a different Facade for the
> HttpModule work.  I've been quite impressed in the past with the
modularity
> of Jakarta's code.

Very nice.

Another piece that is helpful is code that wrappers existing Java classes
and lets them be called as is.  I had a prototype of this up and running
last year - I'm now in the process of reacquainting myself with this code
and getting it back up and running with Beta 2...going from the PDC version
to Beta 1 only required one line of code change, but apparently more
changed with Beta 2.

I'm not proposing this as much more than a convenient way to produce the
scaffolding necessary to get a port up and running quickly.  It may be
useful in the same sense that BSF is useful - for coarse grained
integration of components.

What concerns me about JUMP is that it likely is to be targeted as a one
way migration.  I'd prefer a wider range of options from coarse grained
integration as mentioned above, to J2IL compilers, to porting Java code to
C#.

> Ouch, started thinking about that hypothetical situation with a Java
> compiler, we could compile most of CLASSPATH to get Java libraries, but I
> forgot about sockets, which would likely get hairy.  There are likely a lot
> of other situations that would need to be researched a lot more, not the
> least of which being the Java compiler itself :).

That's a big undertaking.  Simply wrappering the entire JVM can get you up
and running quickly, and then specific items can be tackled individually,
with a running system at all times.

The bigger issues are not higher level concepts such as sockets, but rather
low level details such a strings.  If you require a wrapper class which
adds back in Java interfaces for Strings, then your code requires an extra
step to be called by C# and other languages.  If you don't, then your
compiler needs to find a way to add back in the

Since my approach was to build wrappers in C# instead of IL, I also had to
deal with a number of C# specific issues.  My least favorite, and one that
I think many people will complain with once they realize it is that
interfaces can not define constants.  This means, for example, that you
can't define an enum that might be reference by a method in the same body
of code.  Other issues that I recall off the top of my head include the
event model (solved), and not being able to define methods by the same name
as the class (port enough code and you will find people do some weird
things), and some namespace collision issues (these are complex to
explain).

One I get the code back up and running, if there is any interest, I'll post
a link to it here.

- Sam Ruby