Support for high level languages (Ruby, Python, Java, C#...)

[archived]

I've seen a couple of references to supporting higher level languages for writing device drivers/plug-ins/... (Many folks don't enjoy playing with sharp knifes, small nukes, or c++)  Is there are road map yet for the direction you're hoping to go and timeframe for getting there?  

IMHO, these are the dominate playes these days  (From an x-Product Managers persective anyway):

Wired:
Python is gaining moment fast as the scripting lang. of choice.
C#/Mono - leverages the MS/Java camp.  Very nice language.
Ruby is really great stuff, but lives in relative obscurity. Love it, wished more folks used it.  Lacks good 3rd party library support (wxWindows...)

Tired:
Perl-power to spare, but for smaller scripts and is totally non-maintainable code
Java has a huge installed base, and a huge amount of baggage

Daniel

[archived]

Actually the device is included in the .12 build.  It's Generic Serial Device, and it embeds Ruby.  We're adding support for 2 RS232 controlled A/V devices this week using it: the Devon DVD-A11 and the Denon AVC receiver.

For a 'hardcore' device, you'll still need to do it in C++.  But we're hopeful that 99% of the device drivers can be done with this.  There's no docs for it yet, though.  That should come toward the end of the week.

[archived]

Actually the device is included in the .12 build.  It's Generic Serial Device, and it embeds Ruby.  We're adding support for 2 RS232 controlled A/V devices this week using it: the Devon DVD-A11 and the Denon AVC receiver.

For a 'hardcore' device, you'll still need to do it in C++.  But we're hopeful that 99% of the device drivers can be done with this.  There's no docs for it yet, though.  That should come toward the end of the week.

Hi,

can I give some wote for Perl and Misterhouse too, when the time comes...

Quick question:
- how complicated is DCE message (for instance for media player) ? I'd like to get some guidance for simple procedure:
a. adding template for some simple media device (play,stop,next,prev, what to play...)
b. register device to DCERouter from MH
c. receive and act upon commands from DCERouter...

- I'm currently thinking whether it is compulsory to use DCE library for sending/receiveing messages or is parsing/constructing messages less demanding ?

- How did you embed Ruby - via ruby wrapper around dcelibrary or ... ?

- maybe we could wrap DCELibrary to Perl, and start from there, but that will need more experienced programmer...

Regards,

Rob.

[archived]

The Generic Serial Device is a regular DCE C++, just running an embedded Ruby processor.  Ruby doesn't handle any of the DCE messaging -- that's done by the C++ stuff.

DCE isn't particularly a complex format.  It's basically just a matter of sending, via text over a socket: MESSAGE 1234

where 1234 is the size of the message (the binary data), and what follows is 1234 bytes of binary data that turn into a message.  The only class really needed is the Message class.  The same class could be done in perl, or another language, so they could communicate directly with the router, sending and receiving messages without using the C++ library.

However, since the C++ libraries already exist and are tested, it's probably better to avoid re-writing them in perl, and just using an embedded perl or other interpretor, like we did with Ruby.  However, I know nothing about perl or ruby.  I'd have to get someone else to reply to this if that's the direction you wanted to go.

[archived]

The Generic Serial Device is a regular DCE C++, just running an embedded Ruby processor.  Ruby doesn't handle any of the DCE messaging -- that's done by the C++ stuff.

DCE isn't particularly a complex format.  It's basically just a matter of sending, via text over a socket: MESSAGE 1234

where 1234 is the size of the message (the binary data), and what follows is 1234 bytes of binary data that turn into a message.  The only class really needed is the Message class.  The same class could be done in perl, or another language, so they could communicate directly with the router, sending and receiving messages without using the C++ library.

However, since the C++ libraries already exist and are tested, it's probably better to avoid re-writing them in perl, and just using an embedded perl or other interpretor, like we did with Ruby.  However, I know nothing about perl or ruby.  I'd have to get someone else to reply to this if that's the direction you wanted to go.

Hi,

I think that there are couple of tools that generate Perl wrappers for some linux library. Then it creates Perl library that can be used in Perl programmes. I think this would be right way of doing it (if I remember right there is even same tool, that can generate wrappers for differenct scripting languages - so there could be single generating solution).

http://perl.active-venture.com/pod/perlxs.html

is one of them, another much more general :

http://www.swig.org/

I think that someone more experienced can easily do this. If SWIG would work, you can get wrappers for a lot of languages...

HTH,

Rob.