monkinetic the blog

Dave is making a point on Scripting News regarding IDL (or in this case WSDL) for Frontier, and other non-typed scripting languages. His point is that he cannot generate at runtime the WSDL directly from the code, as can C# or Java developers - b/c their runtimes have information about the types and numbers of parameters to a call.

This means having to handcode the WSDL for a web service in these environments, which can be a PITA if your service is at all large.

I have an idea though. One way to get around this would be to implement a meta-data header for these environments similar to javadoc. I’ll use Frontier as an example.

In Frontier, scripts are outlines. Frontier already has a rich set of functionality dealing with rendering outlines into other formats, esp. HTML. You can use #directives in your outlines, which get translated into information in the symbol table when rendering the outline (or any other datatype for that matter).

So, I would propose a simple set of #directives that can be inserted into a script outline above the actual script code, as a commented block. That block can be grabbed and processed to generate whatever idl format is desired.

This is just an idea, someone with more Frontier experience could come up with a better design. I also know that Perl has Perldoc and POD (inline support for manpages), so including this information in perl scripts in a long tradition in that community.

Also, at least someone is working on WSDL support in Python (which has an easily introspected runtime). “Therefore I am planning to write a WSDL generator that will examine our exposed methods and write out a valid WSDL file.”

So, I think that lack of explicitly typed data should not be the final reason not to support some sort of IDL for web services. There may be other, better reasons, but I have not seen them yet.