From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48, FORGED_GMAIL_RCVD,FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,1eef1e815cf70416 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.157.134 with SMTP id b6mr397622bkx.5.1339692821278; Thu, 14 Jun 2012 09:53:41 -0700 (PDT) Path: e27ni47948bkw.0!nntp.google.com!news1.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Marius Amado-Alves Newsgroups: comp.lang.ada Subject: Re: Distributed Systems Annex, data sharing between programs Date: Wed, 13 Jun 2012 03:55:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <3722dc80-de67-4beb-91c8-e05dda0b8aef@googlegroups.com> References: <8055acf5-188f-4b34-b4f0-83d70fee54f8@googlegroups.com> <96feb838-e0d3-4d06-abf0-79a8e74b5746@e20g2000vbm.googlegroups.com> <54af7ad7-7268-4d84-bafa-542e380a58f6@n16g2000vbn.googlegroups.com> <0d661453-423c-484b-90cd-4e80ffe1db5b@6g2000vbv.googlegroups.com> <1dvxe1yiwtw0q$.6h9nlsnpe5ay$.dlg@40tude.net> NNTP-Posting-Host: 82.155.36.48 Mime-Version: 1.0 X-Trace: posting.google.com 1339585790 25965 127.0.0.1 (13 Jun 2012 11:09:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 13 Jun 2012 11:09:50 +0000 (UTC) In-Reply-To: <1dvxe1yiwtw0q$.6h9nlsnpe5ay$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.155.36.48; posting-account=3cDqWgoAAAAZXc8D3pDqwa77IryJ2nnY User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-06-13T03:55:47-07:00 List-Id: > Our middleware supports synchronous calls, but they are implemented on to= p > of an asynchronous layer as send/request + wait. (Kasakov) (Secret technology?) This thread is fascinating. Make RPC based on messages (Kasakov and others) or vice versa (Obry and oth= ers)? FWIW, I tend towards the latter. It's clearly the Ada way: Ada offers asyncronous control already. Chapter 9. So it's just a matter of= wrapping the RPC with the desired asyncronous logic (a task, the time out = idiom, ATC...) Distribution and synchronicity are orthogonal dimensions. Probably Ada has = been designed with this in mind. Distribution =3D> Annex E. Synchronicity = =3D> chapter 9. Yes, an implementation of Annex E may be based on messages e.g. sockets, an= d therefore asynchrounous RPCs in Ada (let the oximoron pass this time) wil= l compile to an asynchronous-synchronous-asynchronous tower. Maybe there is= a performance penalty here. Maybe for some projects climbing this tower wo= uld take too long, and so they use a message protocol directly for the mess= age abstration. I cannot think of any other reason to depart from the Ada w= ay. (Is it really true that Polyorb is the only Annex E implementation that exi= sts? Or just the only libre one?)