CosmosKey
Suggestion on command/parameter naming
Love this idea, I'm going to want to play with this myself.
When I look at the module though, I tend to think Invoke-PSIS should be broken into multiple commands: Get-PSWebService, Add-PSWebService, Remove-PSWebService, Start-PSWebService, and Stop-PSWebService. Invoke isn't appropriate in my opinion because it implies that you are invoking a command on the web service then and there, not just creating the web service listener (Add-) and starting it up (Start-). I would also have the Add-PSWebService command automatically start the web service as well, and I would rename the ProcessRequest parameter as simply ScriptBlock (to be consistent with many other commands that accept a script block), but having ProcessRequest as an alias for that parameter makes sense. And with that naming, I would call the module PSWebService.
One nice thing about this name is discovery. Intellisense in the more recent versions of PowerShell will pick up on the "Service" part of the name, so if you were to type Get-Serv you should see Get-PSWebService as one of the options. Ditto for Start-Serv/Stop-Serv, etc.
Note that I haven't thought this naming scheme through, this was just my knee-jerk reaction when I saw what you had published.
Kirk out.
Hmm, I think I like your thinking. It seems as if you want to create either a scheduled tasks, a service or an endpoint to host the WebServer. Is that right? I do agree on the Invoke verb being misused. PSWebService or PSWebServer? PSWebService seems to indicate SOAP capabilities. What do you think?
One thing I don't want to compromise on is the ability to start the webserver in a single command, blocking until one hits ctrl+c. This is so convinient when prototyping. We can add other abilities of course. Have a play with how it works and get to understand how the registration of the HttpListner works. It is pretty neat since one can register different processes which all listen to the same port but different relative URLs.
Lets see if others have some other input then we can draw up a bit of a roadmap. :)
Yes, that's how I was seeing it. I like the ability to launch it as a command-line app too, especially for prototyping/debugging. Maybe multiple parameter sets for whatever command is used to set it up (Add-PSWebService/New-PSWebService), so that you can launch it as a service/endpoint or as a command-line webserver. I think I prefer Service over Server, but realistically I could be happy with either.
I'll download it and play with it, see what I can make it do.
Kirk,
Adding it as a service. I hear you. I'll get working on it. Will require a bit of a central repository for listing added "serviced" instances and runtime instances since I feel that a Get-PSWebServer should return both services and runtime instances. Also still want to be able to run up the server as a normal user so not sure where to host the central repository. Maybe in both HKCU for runtime instances and HKLM for services.
First things first. I need a simplified way to check query parameters etc. maybe some better validation etc. So we need a nested module for all these internal functions. For example:
Get-QueryParameter -Name Username Get-UrlRelativePath Get-HttpMethod Test-HttpMethod -Method POST Test-UrlRelativePath -UrlRelativePath "/search"
Also don't believe that there is any form of descent session handling in the HttpListener so a $session object might be needed for server side session variables.