Re: Reporting tools

I always find it a little suspect when people mention "linux" in context
with "dotnet"...

If you are writing a major web application, then deploying it in IIS/Win2003
is surely the best route.

If the Linux requirement is a customer "must have" then of course, the
apache/mono etc stuff comes to play.

But some of the comments appear to be simple Microsoft bashing (I'm not
suggesting that Glen is a Microsoft basher in any way!).

"Tony Gravagno" <g6q3x9lu53001@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
"Glen B" wrote:

.NET is fine, unless you happen to be in a *nix environment and want to
build the reports there.

That's not entirely correct. Using a tool like Visual MainWin you can
write all of your code in .NET and deploy it in *nix. It does this by
(re)compiling the .NET Intermediate Language code into Java byte code
via Mono.

So let's connect the dots here: Write ASP.NET code using the free
Visual Studio Web Developer Express Edition, compile to Java with the
free MainWin, deploy using free Apache/Tomcat. Not bad, eh?

Now let's say I have a software application with the UI in a browser
(e.g. AJAX front-end) and I want to give it a .NET plug. What would I
do to the application to allow it to play in the .NET world?

It's not that simple because .NET is a local Windows service and client
architecture. Javascript is a platform independant technology, so you
wouldn't be able to build a cross-browser/cross-platform product with it
.NET. That's not to say you can't make them all work together with
However, that limits your HTTP services options.

Well... If you look around you'll see companies offering lots of
cross-browser compatible components for ASP.NET. This is how they
work: You drop a component on your ASP.NET design page. The visual
widget that you see is only a generic instance of the control. At
runtime, a browser connects to the server and identifies the
browser-type in the headers. A properly coded control will call a
subroutine to return the proper JavaScript, DHTML, and CSS specific to
that browser. For Ajax-enhanced controls, the script that goes to the
client contains the browser-specific nuances required to implement

ASP.NET doesn't care what kind of client you have - Opera, Safari,
PDA, SmartPhone, Linux, Mac, what-evah. Anyone can write an
Ajax-enabled component like this provided they understand how to
properly code for each browser type - it's essentially just another
CASE statement to support a new client technology. For what it's
worth, you can just as easily export Flash/ActiveScript/Flex using
this same methodology.

Of course you can do this in any language: PHP, Perl, and other
languages all have a CASE/SWITCH statement. Even Pick BASIC can serve
up Ajax via FlashCONNECT, Coyote, etc.

But I don't think any of this answers Dawn's question about plugging
into .NET from some other language. As I mentioned in my other post -
HOW you do it depends on WHAT you're plugging to/from.

I proposed an RFC for communication of MV data, back in 2000. It got zero
interest, apart from a few other propeller heads.

I remember all of that and I think you just hit it on the head. It
was a bit too cerebral Glen, you needed to be a real geek to
appreciate the potential. With the advent of Web Services it seems
your work might be appreciated more these days - some ideas are just
ahead of their time.