[erlang-questions] Erlang RPC over Diameter

[Thomas Lindgren]

--- "Ulf Wiger (TN/EAB)" <ulf.wiger@REDACTED>
wrote:

> 
> Given that a number (> 1) of Erlang people are
> hacking away at 
> Diameter stacks, what would you think about agreeing
> on some
> derived types for carrying erlang information?
...
> One could make it really easy, and encode/decode all
> types as ETerm, and have specific types, EInteger,
> etc.
> coded the same way, but restricted to the
> corresponding
> Erlang types.
> 
> In Diameter parlance, ETerm would be a derived type 
> based on the base type OctetString, but we would
> then
> add the restriction that it conform to the Erlang
> Term format.
> 
> Tuples and lists should perhaps be grouped AVPs: ...

The best format depends on what should be done with
the data. Opaque Erlang data can just be put in an
OctetString with some extra constraints; that should
be straightforward. If the data supposed to be
examined by the diameter application then a more
diameter-oriented data type would be needed.

Is the latter needed though? It just lifts the problem
into the erlang domain, while I think most would
prefer defining more problem-specific AVPs directly,
rather than going via a general "term" data structure,
then restricting that. (I calmly confess I haven't
thought through all the possible uses.)

NB: I'm not aware of any recursively defined AVPs. I'm
not sure that will be greeted with any cries of joy
:-)

In conclusion: transporting opaque erlang data seems
uncontroversial; a set of diameter AVPs mirroring
erlang terms seems less clear a win, but who knows?
Writing down the AVP definitions seems pretty
straightforward.

Best,
Thomas



 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php