Slug: idl-in-non-typed-scripting-environments Date: 2002-01-25 Title: IDL in non-typed scripting environments layout: post

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.<p> 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.<p> 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.<p> 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).<p> 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.<p> 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.<p> 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."<p> 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.</p></p></p></p></p></p></p>