/
2019-06-07 Meeting notes: ListenAtName next steps

2019-06-07 Meeting notes: ListenAtName next steps

Date

Jun 7, 2019

Participants

  • @Kelly Foster

  • @Artur Gajowy

  • @Dominik Zajkowski

  • @Lucius Meredith

  • @Chris Boscolo

  • @Adam Szkoda

  • @Kayvan Kazeminejad

  • @Ovidiu Deac

  • @Timm Schäuble

  • @Tomáš Virtus

  • @Łukasz Gołębiewski

Goals

The purpose of this meeting is to discuss the goals of ListenAtName, to review feedback from dapp developers about their needs, and discuss a strategy for improve this feature.

Discussion topics

Item

Notes

Item

Notes

Resources

Idea: read-only continuation

  • Have a continuation parked at a name that is a subscription. It is read-only. Requests for listening at name should be pooled with an external service.

  • After continuation feature implemented, we could get rid of LFDAN api

  • Most applications want the watcher continuation to fire after finalization. There are some riskier apps that are willing to follow unfinalized data

    • REQUIREMENT a flag “I know what I’m doing (non-finalized data), send me the data anyway

  • Triggering the watcher happens before finalization, but publication can’t happen until there is finalization

    • This requires something that looks for finalization and then triggers the watcher

  • Continuation goes in RSpace so it can be persisted

  • Question: Who pays for executing the continuation?

    • This is an attack vector

    • REQUIREMENT associate a cost with the watcher semantics

  • Question: How do I get the data back? Paramatize the continuation via http?

    • Recommendation to point to an external subscription service (ex Kafka)

  • How do I know the name I’m listening for?

    • Does current LFDAN address this?

    • Greg would prefer a look-up process associated with the registry

      • Challenge is you don’t know the name until it gets to the chain.

        • There is a path to solve that (ex deploy ID)

  • You can only LAN after the name exists and after the the subscription is set up

  • REQUIREMENT: observe data at a particular name

  • QUESTION: If we have a callback, the callback has to be executed. In a distributed system it’s hard to ensure the callback happens once and only once. Who owns the callback?

  • QUESTION: How do we observe changes in values in the channel?

    • The events themselves are the trigger for the watcher continuation. At the movement there is an event to update the name, that is the moment you trigger the watcher to see if there is any finalization.

    • Concern RSpace can’t support this as currently operating

      • Tuplespace tracks checkpoints, nothing else

    • IDEA expose an event log that users can subscribe to (Artur)

Action items

Decisions