Re: 2dsa | !2dsa ?

[Shark8 <onewingedshark@gmail.com>]

On Monday, January 11, 2021 at 8:32:25 AM UTC-7, Dmitry A. Kazakov wrote:
> On 2021-01-11 15:59, Shark8 wrote: 
> > On Thursday, December 24, 2020 at 6:30:59 AM UTC-7, Dmitry A. Kazakov wrote: 
> >> On 2020-12-24 13:02, Maxim Reznik wrote: 
> >>> I forked a older (Garlic) GNAT DSA implementation and found it quite hackable. :) 
> >>> My idea is to implement a WebSocket/WebRTC transport and compile it by GNAT-LLVM to WebAssembly to have distributed Ada applications in a browser. I have a working proof of concept demo already :) 
> >>> 
> >>> https://github.com/reznikmm/garlic/tree/web_socket 
> >> My question is how to proceed without GLADE/Garlic etc. I have DSA 
> >> implemented, e.g. System.RPC. I need GNAT to accept it as such. 
> > What do you mean by this? 
> > How is GNAT "not accepting" it?
> It does not invoke the provided DSA implementation for remote calls.
This is a dumb question, but did you remember to recompile the run-time library?
https://www.cs.fsu.edu/~baker/ada/gnat/html/gnat_ugn_20.html#SEC230
(I'm pretty sure you'd have to, to get a change into DSA behavior.)

> > More, you mentioned the possibility of using a set of tagged-types, "like Storage_Pool", elsethread; is this how you implemented them, or a suggestion for a new standard interface?
> It was a suggestion. The current way is System.RPC see ARM E.5. It seems 
> that merely replacing it is not enough for GNAT.
Given "The package System.RPC is a language-defined interface to the PCS" it seems like that there are two readings:
(1) System.RPC defines the forms with which remote-calls are done, and/or
(2) implements the actual communications.
As it is written, I would think that #1 is the proper interpretation, if this is the case than recompiling System.RPC is "mucking about with the interface" and not much else.

The item "An object of the type Params_Stream_Type is used for identifying the particular remote subprogram that is being called, as well as marshalling and unmarshalling the parameters or result of a remote subprogram call, as part of sending them between partition" seems to indicate that #2 is the proper reading though.

> >> In a more distant perspective I need a work-around of stream attributes. 
> >> They are non-portable, so there must an option to replace them for DSA 
> >> and/or provide a non-stream parameter marshaling when the transport is a 
> >> higher-level protocol, e.g. CANopen, EtherCAT, ASN.1, AMQP etc. For 
> >> these you must map Ada types into the types defined by the protocol. 
> > I have some ideas on how this could be achieved. 
> > I'll make a note for my To-Do list on Byron, but I was thinking that a good method to achieve this for an OS (WRT ASN.1) would be to have at the base a SOM-like system with the base meta-object having a serialize/deserialize pair of methods (with one parameter being the encoding scheme)...
> The problem is that 
> 
> 1. They must doubly dispatch on the object type and on the container 
> type, since there could be any number of containers = encoding/decoding 
> schema. 
Why?
You could have the encoding/decoding method as a parameter.


> 2. They must support chunking. E.g. deserialize cannot be a function.
Why?
I can't think of anything off the top of my head that directly prohibits us from making it a function; at least X'Stream'Input-wise.

> This will get you a whole bunch of nasty problems with partial 
> serialization and indefinite types. [I do not see these resolved without 
> properly done constructors and co-routines.]
I don't see why the partial-serialization is a problem: if you have some type's value to serialize, you're already constrained.
If you're reading from a stream to initialize/reconstruct a type-value, then you're doing X'Stream'Input, right?