Minimal Viable Product

[digitalextremist]

Per journal entry 20190227:

• [ ] Instantiate a single DIF on a host
  • [ ] Create the minimal required services to support
  • [ ] Enrollment
  • [ ] Service discovery / lookup
  • [ ] SDU Protection Flow instantiation with a simple QoS Bidrectional message exchange
• [ ] Create two application processes that understand how to
  • [ ] Enroll in a DIF
  • [ ] Open a flow
  • [ ] Write a message
  • [ ] Read a message
  • [ ] Close a flow

[digitalextremist]

Comments in entry 20190228 refactor the MVP but don't bullet-out a new one.

That entry seems to advocate for a single instance of a Ruby program with multiple threads communicating. I think that's a great starting point, and that leads to my next issue, talking about a reference implementation.

The current Celluloid codebase could be completely gutted in favor of RINA versus Guilds and short the uptake of that concept on the grounds of anticipating RINA in the future, versus writing more abstractions. We're working around foundational issues which RINA solves.

+80% of why I wrote ECell was to try and use your ZeroMQ work on top of Celluloid to try and achieve what your second MVP idea seems to propose. Seen through the eyes of 20190304 this all is just the continuation of @chuckremes personally, perfectly contiguous with the ZeroMQ work. I probably wouldn't have written much of ECell if this all existed in Ruby.

Both ECell and Celluloid dissolve into each other, so my next issue is to propose a reference implementation I call Vertices which is theoretical; a specification only at first. But the refrain of "that's boring" in the journal alone makes me think the approach of marking the target would energize, concretize, and then help realize the underlying proto-rina goals.