[erlang-questions] Erlang RPC over Diameter
Sat Jun 23 18:22:32 CEST 2007
--- "Ulf Wiger (TN/EAB)" <ulf.wiger@REDACTED>
> 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,
> coded the same way, but restricted to the
> Erlang types.
> In Diameter parlance, ETerm would be a derived type
> based on the base type OctetString, but we would
> 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
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
More information about the erlang-questions