On Sunday, January 26, 2003, at 01:01 PM, Mark S. Miller wrote:

> At 09:50 AM 1/26/2003 Sunday, Robert Withers wrote:
>> fantastic!   I have a couple of questions:  Do we need to provide a
>> capability interface to plugin code?
>
> I don't know. Please tell me about plugin code.

see http://minnow.cc.gatech.edu/squeak/464    Plugins are generated to 
c and compiled as shared libs.  They get initialize with an 
interpreterProxy that gives them access to the virtual machine.  Squeak 
code can call primitives in the plugin.  We may want to think about 
both directions as capabilities and look into having an eventual msg 
model at this interface.   Often plugins are used to either speed 
things up or provide access to platform specific I/O resources and api.

>
>>  Could this help us support function
>> callbacks, into the image, so we could use squeak as a shared library 
>> to
>> another program?
>
> I don't know, probably because I don't yet know about plugins.

We can callout with FFI, but we have never really worked on allowing 
external programs to call back into squeak.   The concurrency and 
asynchrony of message passing, from the perspective of the vm, might 
allow for eventually-sent interrupts.

>
>>    Forget about my authentication ramblings, please.
>
> Ok, I've already forgotten who said this ;).
>
>> PS.  Mark, I am adding handling of these three messages to the CapTP
>> (id -> class).  Does this conflict anywhere?
>>
>>                at: 13 put: CapTPAvailableProtocolsMessage;
>>                at: 14 put: CapTPSwitchProtocolMessage;
>>                at: 15 put: CapTPAcknowledgeProtocolMessage;
>
> No conflict, but what's the ack for? I think you only need the first 
> two.

your are right.  I think i wrote it when we were discussing having to 
do a round trip to change the protocol.

cheers,
rob