FFI | FFIExternalSharedPoolPlatform -> ExternalPlatform or FFIPlatform or ... ?



Hi, all!

I want to generalize FFIExternalSharedPoolPlatform to use it for both external pools (first element in generated array) and external structures (ExternalStructure class >> install).

I need a new name. :-)

- ExternalPlatform ... too close to SmalltalkImage >> #platform* ?

- FFIPlatform ... reads FFI-specific, which could be good enough for now

Hi Eliot & Marcel,

In reading about this effort, I got to thinking. I am curious what the format of the external structure description would be in: the encoding. AS this is very useful for multiple languages to interact through a pool of structure definitions and pool elements.

I am having good success at building ASN1 Structures under a naming system that can interoperate in Squeak[1] and Java[2]. I am using these structure definition ASN1 implementations to un/marshall the handshake messages in ParrotTalk. The great thing about ASN1 is that the ASN1 structure type oid is carried within the marshallings so they can unpack to the correct object. So, I can pass predefined structures between them, at the ParrotTalk layers (layers 5 & 6a).

I continue to have Raven [3][4] (networked SqueakELib layer 7) on the back burner, with a failure in 3-way gift exchange. 2-way networked interactions do work. It works in Squeak, using the STON un/marshalling framework. As I ponder future efforts, I think about how to get Squeak AND Java interoperable at this distributed capabilities layer (layer 7). Port STON to Java, like I did the ASN1 framework? Or settle on another marshalling specification.

Alright, I consider how many objects are #passByCopy. It is a finite set, precluding any new development. In Squeak, a [#passByCopy ^ true] can be set for a given object Address, then marshalled in the client. Will the server know about it and what to do with it? Possibilities arise in such a direction with mobile on-demand code packages, connected through a naming service (interface repository). In the beginning, hand loading new #passByCopy classes will suffice.

All other NOT #passByCopy, #passByReference object classes are substituted in the connection specific Scope with FarRef&RemotePromiseDescriptions, as well as resolvers, reactors, redirectors, #whenMoreResolved: block and so on. All of these messages are known. The issue is with Domain object classes. As previously observed, all #passByCopy are predefined, while the rest get ReferenceDescriptions.

The conclusion is that the ASN1 framework can operate on un/marshalling distributed capabilities, in both Squeak & Java. We pass nothing not predefined, so use of ASN1CompositeWrappers and ExternalContexts are not currently used. When I finish SSL/SSH/Signal in the ThunkStack framework, I will shift to Raven and fix it up, and switch to ASN1 un/marshalling. This would be best, I think.

Andso, my question to y'all. Do you think ASN1 encoding be useful to FFIPlatformDescriptions, as a candidate shared memory encoding description?

Kindly,
Rabbit

[1] ParrotTalk Squeak - http://www.squeaksource.com/@LKzAZY9g1KxsoLQ6/uqGqCREr
        Installer ss
                project: 'Cryptography'; install: 'ProCrypto-1-1-1';
                project: 'Cryptography'; install: 'ParrotTalk'.

[2] ParrotTalk Java - https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/README.md
        Load ASN1 then load ParrotTalk.

[3] Raven Squeak - http://www.squeaksource.com/@hE_aRAlYwK8xEND4/ewTo-gzO
        First load STON, then Raven.

[4] Raven Java - https://github.com/CallistoHouseLtd/Raven/blob/master/README.md
        Not currently interoperable with Squeak.

Here are sample ThunkStacks for ParrotTalk, SSL (getting very close!), SSH (not yet ported) and the imagined Signal stack (not yet implemented)

Protocol Probing: Here is the imagined probes for auto detection of protocol to handle all protocols.

Here we have the PAPAS: ParrotTalk Automated Protocol Analyzer & Selector.

On May 26, 2020, at 6:54 AM, Marcel Taeumel [hidden email] wrote:



Hi, all!

I want to generalize FFIExternalSharedPoolPlatform to use it for both external pools (first element in generated array) and external structures (ExternalStructure class >> install).

I need a new name. :-)

- ExternalPlatform ... too close to SmalltalkImage >> #platform* ?

- FFIPlatform ... reads FFI-specific, which could be good enough for now

Since it is more descriptive of the interface than the interface it self, I suggest FFIPlatformDescription or similar

I really like the idea of generalizing to include structure description.

- ...

OR: Just add SystemPlatform to "System-Support" to have a platform object for all kinds of libraries? We already have SystemVersion.

Best,

Marcel