OpenEdge Enhancement Request: Enable interop between the AVM

Posted by abe.voelker on 27-Mar-2013 11:03

I sent this yesterday to openedge-enhancements@progress.com but last time I didn't get any responses to my emails, so I'll post here once again as I anticipate I won't get one this time either.  Do other people normally get a response, or are you supposed to have a license for that?  If this request goes through it would be cool to add ABL support for Protocol Buffers or Thrift for message serialization but I don't think any PSC intervention is required for that.

A description of the request, with as much detail as possible

Enable the AVM to interface fully with the ZeroMQ (ØMQ) library.  I tried to write a binding about a year ago using the 0MQ .dll, but the AVM crashes when calling zmq_init.  Checking the version with zmq_version works fine so I'm pretty sure my foreign function interface was set up properly.
What the advantage(s) would be to you if this feature was available
Interfacing ABL code with non-ABL systems is currently a headache.  A popular technique is implementing the STOMP protocol in pure ABL and interfacing with an AMQP message broker that supports STOMP (like RabbitMQ or ActiveMQ).  The downsides to this approach are (at a minimum) that you
  • must rely on an external service for handling message delivery and receipt
  • must hit the network to send and retrieve messages
  • are restricted to message topologies and semantics defined by the AMQP broker (e.g. ActiveMQ uses topics and queues and an XML message format)
0MQ could obviate these issues and simplify matters for ABL programs by providing a flexible transport layer to be used for external communication, still leaving the design of the message topologies (0MQ builds in many different socket types that can be combined) and message formats (which 0MQ is completely agnostic to) up to the user.
 
Any work-arounds to meet your needs in this area today.
0MQ contexts can be initialized and messages sent/rec'vd from within an AVM running on Windows by using the CLR / .NET bridge (calling .NET code).  The problem with that is that it only works on Windows (and not Linux/Unix machines) so is not a portable solution.

All Replies

Posted by Jens Dahlin on 27-Mar-2013 11:50

I sent in a request (for a built-in ABL-based REST web service client) the same way this Sunday and have not received any answer either.

We do have a license, several infact, but we have first line support from a Progress Partner - don't know if that makes any matter.

This thread is closed