<html><head></head><body>
    <p>Hi Eliot & Marcel,</p>
    <p>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.</p>
    <p>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). <br/>
    </p>
    <p>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. <br/>
    </p>
    <p>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.</p>
    <p>All other NOT #passByCopy, <b>#passByReference</b> 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.</p>
    <p>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.</p>
    <p>Andso, my question to y'all. Do you think ASN1 encoding be useful
      to FFIPlatformDescriptions, as a candidate shared memory encoding
      description?</p>
    <p>Kindly,<br/>
      Rabbit</p>
    <p>[1] ParrotTalk Squeak -
      <a class="moz-txt-link-freetext" href="http://www.squeaksource.com/@LKzAZY9g1KxsoLQ6/uqGqCREr">http://www.squeaksource.com/@LKzAZY9g1KxsoLQ6/uqGqCREr</a><b><br/>
                Installer ss<br/>
                        project: 'Cryptography'; install:
        'ProCrypto-1-1-1'; <br/>
                        project: 'Cryptography'; install: 'ParrotTalk'.</b></p>
    <p>[2] ParrotTalk Java -
      <a class="moz-txt-link-freetext" href="https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/README.md">https://github.com/CallistoHouseLtd/ParrotTalk/blob/master/README.md</a><b><br/>
                Load ASN1 then load ParrotTalk.</b></p>
    <p>[3] Raven Squeak -
      <a class="moz-txt-link-freetext" href="http://www.squeaksource.com/@hE_aRAlYwK8xEND4/ewTo-gzO">http://www.squeaksource.com/@hE_aRAlYwK8xEND4/ewTo-gzO</a><b><br/>
                First load STON, then Raven.</b></p>
    <p>[4] Raven Java -
      <a class="moz-txt-link-freetext" href="https://github.com/CallistoHouseLtd/Raven/blob/master/README.md">https://github.com/CallistoHouseLtd/Raven/blob/master/README.md</a><b><br/>
      </b><b>        Not currently interoperable with Squeak.</b></p>
    <p><b><br/>
      </b></p>
    <p><b>Here are sample ThunkStacks for ParrotTalk, SSL (getting very
        close!), SSH (not yet ported) and the imagined Signal stack (not
        yet implemented)<br/>
      </b></p>
    <p><img moz-do-not-send="false" src="cid:part1.B5B9C613.A672B593@pm.me" alt="" width="708" height="377"/></p>
    <p><b>Protocol Probing: </b>Here is the imagined probes for auto
      detection of protocol to handle all protocols.<br/>
    </p>
    <p><img moz-do-not-send="false" src="cid:part2.F016D8C0.4F46B4FB@pm.me" alt="" width="708" height="581"/></p>
    <p><b>Here we have the PAPAS: ParrotTalk Automated Protocol Analyzer
        & Selector.</b></p>
    <img moz-do-not-send="false" src="cid:part3.7A13382E.138F5867@pm.me" alt="" width="706" height="628"/>
    <p><br/>
    </p>
    <div class="moz-cite-prefix">On 5/26/20 1:15 PM, Eliot Miranda
      wrote:<br/>
    </div>
    <blockquote type="cite" cite="mid:D44EFD04-17D9-4913-A825-22985526D1DE@gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>
      <div dir="ltr"><br/>
      </div>
      <div dir="ltr"><br/>
        <blockquote type="cite">On May 26, 2020, at 6:54 AM, Marcel
          Taeumel <a class="moz-txt-link-rfc2396E" href="mailto:marcel.taeumel@hpi.de"><marcel.taeumel@hpi.de></a> wrote:<br/>
          <br/>
        </blockquote>
      </div>
      <blockquote type="cite">
        <div dir="ltr">
          <div id="__MailbirdStyleContent" style="font-size:
            10pt;font-family: Arial;color: #000000">Hi, all!
            <div><br/>
            </div>
            <div>I want to generalize FFIExternalSharedPoolPlatform to
              use it for both external pools (first element in generated
              array) and external structures (ExternalStructure class
              >> install).</div>
            <div><br/>
            </div>
            <div>I need a new name. :-)</div>
            <div><br/>
            </div>
            <div>- ExternalPlatform ... too close to SmalltalkImage
              >> #platform* ?</div>
            <div>- FFIPlatform ... reads FFI-specific, which could be
              good enough for now</div>
          </div>
        </div>
      </blockquote>
      <div><br/>
      </div>
      Since it is more descriptive of the interface than the interface
      it self, I suggest FFIPlatformDescription or similar
      <div><br/>
      </div>
      <div>I really like the idea of generalizing to include structure
        description.<br/>
        <div><br/>
          <blockquote type="cite">
            <div dir="ltr">
              <div id="__MailbirdStyleContent" style="font-size:
                10pt;font-family: Arial;color: #000000">
                <div>- ...</div>
                <div><br/>
                </div>
                <div>OR: Just add SystemPlatform to "System-Support" to
                  have a platform object for all kinds of libraries? We
                  already have SystemVersion.</div>
                <div><br/>
                </div>
                <div>Best,</div>
                <div>Marcel</div>
              </div>
              <span></span><br/>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
  

</body></html>