[erlang-questions] comparison with opensaf

[Ola Andersson A]

No, not really equivalent. IMM provides much more functionality than mnesia. It’s not just a data store.
IMM consist of two parts; OM and OI. OM is the Object Management API. The OI part is a set of callbacks that lets the user provide an ObjectImplementer for an object or class of objects.
IMM has both persistent configuration objects and dynamic runtime objects. Runtime object may also be cached.
Configuration objects may contain runtime attributes and the other way around. Runtime objects and attributes are owned by the ObjectImplementer.
For configuration objects an OI provides validation functionality with the possibility to reject a so called CCB (Configuration Change Bundle).

This is just the basics of IMM. There is a lot more available. OpenSAF has also extended the SAF IMM specification with additional functionality.

From: Sashan Govender [mailto:sashang@REDACTED]
Sent: den 26 juli 2016 05:11
To: Ola Andersson A <ola.a.andersson@REDACTED>; Eric des Courtis <Eric.desCourtis@REDACTED>
Cc: Erlang <erlang-questions@REDACTED>
Subject: Re: [erlang-questions] comparison with opensaf

Regarding IMM would it be correct to say it's roughly equivalent to mnesia? I'm just trying to draw up rough equivalences between the OpenSAF services and those in the Erlang/OTP. From what I have read about mnesia it provides a persistant data store that tries to be highly consistent. From http://learnyousomeerlang.com/mnesia it says 'Mnesia sits on the CP side'. IMM has the same property. In fact it tries very hard to be consistent and sacrifices availabilty by not allowing writes for several minutes in some cases while it sorts itself out. It's typical usage scenario is in storing the configuration of a cluster, which I'm guessing mnesia can do as well.

On Mon, Jul 25, 2016 at 11:42 PM Ola Andersson A <ola.a.andersson@REDACTED<mailto:ola.a.andersson@REDACTED>> wrote:
I have implemented parts of the SAF specifications in Erlang. IMM is definitely one of the most ridiculously overcomplicated specifications I have seen.
My hat off to the developers of OpenSAF for successfully creating a working implementation in C. It's hard enough to do it in Erlang but it must have been a nightmare developing in C. I haven't checked how many LOC it is but I'm guessing it's a lot.


> -----Original Message-----
> From: erlang-questions-bounces@REDACTED<mailto:erlang-questions-bounces@REDACTED> [mailto:erlang-questions-<mailto:erlang-questions->
> bounces@REDACTED<mailto:bounces@REDACTED>] On Behalf Of Sashan Govender
> Sent: den 24 juli 2016 06:38
> To: Eric des Courtis <Eric.desCourtis@REDACTED<mailto:Eric.desCourtis@REDACTED>>
> Cc: Erlang <erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>>
> Subject: Re: [erlang-questions] comparison with opensaf
>
> I couldn't agree more. The amount of documentation doesn't correlate with
> quality, and yes I think OpenSAF is over engineered, to say the least.
>
> On Sun, Jul 24, 2016 at 12:10 PM, Eric des Courtis
> <Eric.desCourtis@REDACTED<mailto:Eric.desCourtis@REDACTED>> wrote:
> > Personally I think it's complicated for nothing.   The amount of
> > documentation has nothing to do with how well it is documented. If you
> > have to read 500 pages to understand what a supervisor does that seems
> > like massive over engineering.
> >
> >
> > On Fri, Jul 22, 2016, 8:46 PM Sashan Govender <sashang@REDACTED<mailto:sashang@REDACTED>>
> wrote:
> >>
> >> Not sure which documentation set you saw but the one over here looks
> >> quite detailed. The AMF documentation alone is 500 pages.
> >>
> >> http://devel.opensaf.org/SAI-AIS-AMF-B.04.01.AL.pdf
> >>
> >> AMF as far as I can tell is like the OTP supervisor process.
> >>
> >> In terms of industry applications I know it's used in Ericsson's DSC
> >> (Diameter Signalling Controller).
> >>
> >> On Sat, Jul 23, 2016 at 12:58 AM, Eric des Courtis
> >> <Eric.desCourtis@REDACTED<mailto:Eric.desCourtis@REDACTED>> wrote:
> >> > This is a very hard question to answer because I would say OpenSAF
> >> > is rather obscure. But I can tell you that while there are some
> >> > overlaps between the two technologies particularly when it comes
> >> > design patterns. The fact that Erlang is done entirely from the
> >> > ground up (language, runtime, otp patterns
> >> > etc...) specifically for high availability means that you should in
> >> > theory experience much less friction when designing this sort of
> >> > system in Erlang.
> >> >
> >> > My feeling from looking at the documentation is that this isn't
> >> > well documented. In short I wouldn't consider is competition to
> >> > Erlang in it's current state for any project.
> >> >
> >> > On Thu, Jul 21, 2016 at 9:42 PM, Sashan Govender
> >> > <sashang@REDACTED<mailto:sashang@REDACTED>>
> >> > wrote:
> >> >>
> >> >> Hi
> >> >>
> >> >> I'm interested if anyone has done a comparison the Erlang OTP and
> >> >> OpenSAF.
> >> >> It seems to me there is a significant amount of overlap in the but
> >> >> I don't have the expertise in both systems to form a comprehensive
> >> >> picture. As far as I can tell mnesia is like OpenSAF IMM. They can
> >> >> both be used as configuration databases for a cluster. They both
> >> >> are strongly consistent. I know IMM certainly favours consistency
> >> >> over availabilty. OTP is obviously in Erlang while OpenSAF is in
> >> >> C/C++. Any comparisons out there about these two systems? Or am I
> >> >> wildly off the mark thinking that they are similar?
> >> >>
> >> >> _______________________________________________
> >> >> erlang-questions mailing list
> >> >> erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
> >> >> http://erlang.org/mailman/listinfo/erlang-questions
> >> >>
> >> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160726/cec29064/attachment.htm>