GUI For ISAPI Module - Good Idea? Bad Idea? How? - Inetserver

"Le Chaud Lapin" <jaibuduvin@gmail.com> wrote in message
news:1194938385.120092.94930@57g2000hsv.googlegroups.com...
> Hi All,
>
> It my intention to make an ISAPI module that requires significant
> configuration. The nature of the defining the configuration strongly
> suggest that a GUI is necessary, yet I would very much rather avoid
> making a separate tool just to allow the user to define configuration
> files to be loaded by the module when it starts.
>
> What framework does IIS provide, if any, for allowing modules to have
> their own GUI?
>

The only option you have is to extend the schema for the Metabase. That way
you can use the Metabase editor as the GUI for configuring the values used
by the ISAPI filter.

My preference would be to add a section to a Web.Config file. The build
some a GUI with .NET Windows Forms or ASP.NET (depending on how you'd like
to provide access to the configuration).

--
Anthony Jones - MVP ASP/ASP.NET

On Nov 12, 11:19 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> Hi All,
>
> It my intention to make an ISAPI module that requires significant
> configuration. The nature of the defining the configuration strongly
> suggest that a GUI is necessary, yet I would very much rather avoid
> making a separate tool just to allow the user to define configuration
> files to be loaded by the module when it starts.
>
> What framework does IIS provide, if any, for allowing modules to have
> their own GUI?
>
> TIA,
>
> -Le Chaud Lapin-


Prior to IIS7, IIS does not provide any support for its extension
developers.

IIS7 is a different story. It is completely customizable -- the server
engine is pluggable, its configuration system extensible, and UI is
modular -- so you can write an IIS7 module, with its own configuration
and GUI in .Net. It's a proven formula because all of IIS7 is written
that way already -- you can view IIS7 as Microsoft shipping some pre-
fabricated modules, configuration extensions, and modular GUI
components which as a whole result in IIS6-like behavior.

Prior to IIS7, my preference for server-side module configuration is a
simple text-based configuration file. I imagine most server admins
will make the configuration once and copy/automate its deployment to
the server farm. Forcing UI interaction is probably not the long-term
strategy.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Nov 13, 10:36 pm, David Wang <w3.4...@gmail.com> wrote:
> Prior to IIS7, IIS does not provide any support for its extension
> developers.
>
> IIS7 is a different story. It is completely customizable -- the server
> engine is pluggable, its configuration system extensible, and UI is
> modular -- so you can write an IIS7 module, with its own configuration
> and GUI in .Net.

I see...so you're saying if I use .NET, it is possible to have a
single DLL that does everything. Is that right? What about straight C+
+/COM?

> It's a proven formula because all of IIS7 is written
> that way already -- you can view IIS7 as Microsoft shipping some pre-
> fabricated modules, configuration extensions, and modular GUI
> components which as a whole result in IIS6-like behavior.
>
> Prior to IIS7, my preference for server-side module configuration is a
> simple text-based configuration file. I imagine most server admins
> will make the configuration once and copy/automate its deployment to
> the server farm. Forcing UI interaction is probably not the long-term
> strategy.

This was my original strategy, but since the data structures are midly
complex, I thought about using a GUI. If I can get away with flat
files, should I continue to do that in IIS 7.0 or should I use a GUI?

Finally, for someone writing an ISAPI thing today, one that will run
on servers farms at ISP's everywhere, would you recommend using a
module or something that is more backward compatible. I'm guessing
that almost all reputable ISP's are already using IIS 7.0 by now.

-Le Chaud Lapin-

On Nov 14, 2:56 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> On Nov 13, 10:36 pm, David Wang <w3.4...@gmail.com> wrote:
> I see...so you're saying if I use .NET, it is possible to have a
> single DLL that does everything. Is that right? What about straight C+
> +/COM?

IIS7 server-engine and configuration extension can be written in
native code. That is what IIS7 does. The IIS7 UI is managed code,
so .Net is preferred.

> > Prior to IIS7, my preference for server-side module configuration is a
> > simple text-based configuration file. I imagine most server admins
> > will make the configuration once and copy/automate its deployment to
> > the server farm. Forcing UI interaction is probably not the long-term
> > strategy.
>
> This was my original strategy, but since the data structures are midly
> complex, I thought about using a GUI. If I can get away with flat
> files, should I continue to do that in IIS 7.0 or should I use a GUI?

For IIS7 I would re-leverage its infrastructure. It gives you tight
integration within its UI, web.config files, and core engine such that
everything looks consistent.

However, none of this is backwards compatible with IIS6, so it really
depends on your needs and requirements.

>
> Finally, for someone writing an ISAPI thing today, one that will run
> on servers farms at ISP's everywhere, would you recommend using a
> module or something that is more backward compatible. I'm guessing
> that almost all reputable ISP's are already using IIS 7.0 by now.


Actually, IIS7 Server-version has not shipped yet (will ship with
Windows Server 2008). IIS7 Client-version has released with Windows
Vista and gives preview of what is to come.

I do not expect ISPs to be running predominantly IIS7 until something
like 2010 at the earliest. IIS6 is currently mainstream even though it
was released back in 2003, and people still run IIS5 on Windows 2000.
My suspicion is that IIS7 won't overtake IIS6 unless someone comes out
with a few killer modules to illustrate how it offers superior
flexibility and configurability than IIS6.

So if you want something to run on server farms for the next couple of
years, ISAPI is the way to go. And if you want to bet on IIS7, then I
suggest going completely native with IIS7's integration and framework.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//