So the design question becomes how do you replicate the NamingService? Thinking Kafka, you scale out the number of naming services running. Thinking DistributedELinda, what?

Duplicated DELindas monitored and managed by self-same namingService. Have a replication of running NamingServices in the namingTuple (presence) but only one leader, actively consuming events. It’s persistent through use of distributed HDFS. If the leader NamingService falls over, with a Notification message or not, heartbeat fails, for instance, detection results in a new leader promotion for a quiescent replica. It’s retrieves all needed state from HDFS and rocks on. No message loss, state removed immediately. In fact all live Vats are registered and monitored. As a request to chat can find an active friend, as Alice would like to speak to Bob, god forbid. Thus a connectionReplicaBridging can occur between them.

So we have the features of
-> connectionReplication, opportunistic production (publish) & consumption (subscribe)
-> serviceReplication, where replica leader election is present.

An ELinda Sup for all Services can provide data persistency with HDFS. Let it’s Brokers manage their patricians. So ELindaPersists!

Fault-tolerance.

Have a good one; keep it, light.
Kindly,
rabbit
. .. … ‘…^,^


Sent from Callisto House Mobile :: decentralized mobile homeless solutions

Der Anführer kontrolliert alles,
🐇🐇🐇🐇🐇🐇

> On Oct 9, 2022, at 01:15, rabbit <rabbit at callistohouse.org> wrote:
> 
> ELinda (ELindaSubspace) holding further ELindas, now a tree. With a parent until self-referencing throws a BOSSNotification gets thrown and handled.
> 
> Parents or sub spaces can be FarCachingEventuals for distribution.
> 
> The matching will check all children for matches, then the parent, perhaps other siblings too. DirectorySlash notation for tupleID, ‘/naming/rabbt/services/vat.1675234/stats’
> 
> Have a good one; keep it, light.
> Kindly,
> rabbit
> . .. … ‘…^,^
> 
> 
> Sent from Callisto House Mobile :: decentralized mobile homeless solutions
> 
> Der Anführer kontrolliert alles,
> 🐇🐇🐇🐇🐇🐇
> 
>>> On Oct 9, 2022, at 00:17, rabbit <rabbit at callistohouse.org> wrote:
>>> 
>> ESqueak.alpha now includes ReedSolomon Error Correcting codes.
>> 
>> The Vatz priorityz are
>> #EMERGENCY <$Z>
>> #PRIORITY <$P>
>> #WELFARE <$Y>
>> #ROUTINE <$R>
>> 
>> Stored in a tuple <priority ! eventName ! recieverID ! senderID ! EncryptedArchivedEvent>. 
>> 
>> #sub: easily checks tuple first oneOf: {$R | $Y | $P | $Z}.
>> 
>> PriorityVat subs ELinda, the vat-local ELinda for all, holding ESubspaceArrays for each priority.
>> 
>> What else? #ewhen:send:… & etriggerEvent:  using the LindaZVat for centrally stored EEvents and ERegistrations?
>> 
>> Create sub spaces on the fly each new ASN1Modules are defined? Therefore the keys to sub spaces are themselves tuples, so tupleMatching in ELindas #sub: 
>> 
>> Herself an ETupleSpace, now a Sub of ESubspace. ETuple detect: uses LindaMatching…so <applicationID ! Priority emergency. ! Event>.
>> 
>> Please understand where I’m coming from. I’m holed up in my recliner as the newly applied bioengineered skin activated over my heel ulcer in hopes it advances my healing. I’m to be raising my leg. I am not to disturb it so I’m on my iPhone and sending an email is the best way to store a journey entry I can access later. So I share my thoughts, also for the sake of transparency. CheerZ!!
>> 
>> Have a good one; keep it, light.
>> Kindly,
>> rabbit
>> . .. … ‘…^,^
>> 
>> 
>> Sent from Callisto House :: decentralized mobile homeless solutions
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221009/471405af/attachment-0001.html>