15 September 2004

Perl for .NET

The afternoon started of with a session on Perl for .NET Environment by Jonathan Stowe. I assume Jonthan will update his computing links page with details of this talk in time :-)

Notable in the audience was a strong presence of ActiveState dudes, well known for their excellent support of Perl (and other dynamic languages like Python and Tcl) for Windows platforms, and sell excellent tools, and give stuff away as open source as well. I'm sure this topic is key for them.

There was a brief discussion of reuse, and the obvious fact the the Comprehensive Perl Archive Network (CPAN) is the word's largest open library of reusuable code was mentioned. The stats today are: online since 1995-10-26; 2507 MB 260 mirrors; 3863 authors 6893 modules.

Jonathan presented an overview of .NET and discussion of why interoperability was a priority for the Perl community (and indeed for all software). I think the audience was receptive, after all Perl has always defined itself as a glue language linking other software components in useful ways to improve funtionality.

His basic structure was to say that there are three ways to interoperate:

  • Exchanging XML Documents (datasets, xml serialisation, configuration)

  • HTTP Remoting (serialisable objects, marshalbyref objects)
  • Web Services

One of the easiest ways for Perl to interoperate is to have Perl serialise an object into an XML structure (using XML::Simple) and use this to exchange data with other .NET (or indeed any web service). However, there are limitations with this approach.

Jonathan did mention that a problem people have is assuming that they can call remote constructors and then they make assumptions about what they can access remotely, whereas all this actually depends on the implementation of that remote "object". Personally, I like to think of web services as not being at all like CORBA (remote object references) but as being essentially a message passing mechanism without any assumption that you ever comunicate with the same remote object. If you never think of it as communicating with a remote object, then you are less likely to make these conceptual errors.

Posted by mofoghlu at September 15, 2004 1:40 PM | TrackBack