I have been mulling this over. It seems to Me that the difference between Kafka and EventualLinda (sic) is durability. Kafka stores all events on multiple server replicated partitions, which writes it through their Log object as chunks of data onto disk (sector writes?). Still it’s persisted on multiple machines.

EventualLinda is not persistent. If stores the events (#asTuple #asTupleIncoming: in | out) in memory so removal is directly done.

Andso I’ll use EventualLinda and be happy. Kafka use for later will provide store and forwards capability and let’s not worry about auto-compaction tuning until we’re there. 🐰🐇🐇🐇.

—-

I have published Use of ELinda to subclass ETupleSpace as EventualLinda, an alias name. The following classes got subclasses from this, but do not yet use it. #green329.

Note: the ThunkStack class remained subclasses from OrderedCollection to keep ordering. Here’s the new class structure across several packages:

-> ETupleSpace --> EventualLinda —-> ASN1Module; ASN1Scope

—-> TSSessionServer

-—-> PTSessionServer

—-> TraceMonitor

—-> AbstractEventual

—-> more to come in remote promises.

There is 1 EventualLinda per Vat as an EventualProcess localVariable. A call to localVat Linda should do. Thus all Linda activity in that process uses the same Linda: all eventuals (pending sends in local promise, EventualStream access to events from a NearEventual, for distributed streaming, servers store connections and register eventual patternMatchTuples to react to #connectionSuccessful & #connectionClosed, #dataAvailable…match with which…(RegEx?, Linda?, Prolog?). ASN1Modules will use to store types of different classTag. Scope will store the RemoteObjectMemory remote references and allow

self when: patchXxxTuple send: [:tuple | self processXxxTuple: tuple].

Meanwhile, the SecurityOps and Operations classes will also use this Vat’s Linda. Any use of a Collection and smart asTuple converters are candidates for using a Linda. Strategize the match implementation… #buildLindaMatchBlock, #buildPrologMatchBlock, #buildRegExMatchBlock.

Which Way is Which What?

Have a Good One; Keep it, Light. Kindly, rabbit . .. … ‘…^,^

Sent from Callisto House :: decentralized mobile homeless solutions

On Oct 4, 2022, at 22:34, rabbit rabbit@callistohouse.org wrote:

 Good evening friends. This is a question regarding using Kafka to implement fault-tolerant messaging between distributed object-capabilities, Al la E. At issue is the around the bees’ knees approach to consuming an event once and deleting it out of all replicated partitions, immediately. This dodge is to somehow tell all relevant partitions that it is marked for deletion, then you have to request a partition compression to actually see the event removed from Kafka’s durable disk Log.

This is a real ObjectMemory. Could a mark and sweep eliminate such a marked-for-deletion event, more quickly?

My design is that ParrotTalk be as the secure session under & between Kafka services and vice-versa too. Remote Promises will talk to ParrotTalk which is a Kafka Session underneath, itself using a SecureSession. As RemotePromises publish / send DeliverMessages to an object in a different Vat, with a RemoteResolver registered back into the originating Vat stored into the RemoteObjectMemory (called the Scope of a RemotePromiseSession ), publishing into replicated partitions, consumed by the receiver, fault-tolerant messaging.

Compaction! That’s the correct term, is it not? Be well.

Have a Good One; Keep it, Light. Kindly, rabbit . .. … ‘…^,^

Sent from Callisto House :: decentralized mobile homeless solutions