Language Bindings for Erlang

[Jeff Crane]

> Start by inventing your own protocol which does a
> _subset_ of what you
> ultimately want

Erlang uses a standard protocol, which can implement
any communication I desire anyways. Inventing a new
protocol sounds ridiculous.

> runn that protocol over
> stdin/stdout via the
> 'port' mechanism.

As per interoperability:

1.4.2 C Program
On the C side, it is necessary to write functions for
receiving and sending data with two byte length
indicators from/to Erlang. By default, the C program
should read from standard input (file descriptor 0)
and write to standard output (file descriptor 1).
Examples of such functions, read cmd/1 and
write cmd/2, can be found in the file erl comm.c [page
24].
Note that stdin and stdout are for buffered
input/output and should not be used for the
communication with Erlang!
---
Given the complexity and vagueness associated with
almost all things erlang, it's not surprising to
receive conflicting information anymore. I'm not going
to bother with that.

> An observation: I don't understand why you want
> "middleware". That
> suggests you're either over- or under-specifying the
> problem.

I dont understand how I'm not being understood. The
question remains, how to best glue ANY LANGUAGE to
erlang. Given the lack of choices in
graphics/input/output handling this is probably what
kills most people interest in the language. Gluing
erlang to another language seems necessary for any
learning project.

> An observation: I don't understand why you want
> "middleware". That
> suggests you're either over- or under-specifying the
> problem.

Why is it hard to understand that there's no bindings
for erlang? I dont understand why Erlang advocates so
strongly insist on using erlang for everything. It
seems LOGICAL to use another language for media and
since C is all you have to bind to, it becomes
middleware for whatever you already have or have
talent for.


--- Matthias Lang <matthias@REDACTED> wrote:

> Jeff Crane writes:
> 
>  > I want to forward messages from Erlang to and
> from a
>  > Python GUI via middleware. Would a C Port, C
> Node, or
>  > C Driver be more approriate?
> 
> Your question doesn't have a clearcut answer,
> because "appropriate"
> depends on how you want to weigh different factors
> and what _your_
> particular skill and experience is.
> 
> My suggestion:
> 
> Start by inventing your own protocol which does a
> _subset_ of what you
> ultimately want, and then runn that protocol over
> stdin/stdout via the
> 'port' mechanism.
> 
> "C Nodes" and linked-in drivers ("C driver") come
> under the general
> heading of "complicated and trouble-prone".
> 
> An observation: I don't understand why you want
> "middleware". That
> suggests you're either over- or under-specifying the
> problem.
> 
> Matthias

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com