RFP 158 Distributed Eventing about design HOT 5 OPEN

Comment author: @bosschaert

Created attachment 56
RFP 158 - current draft

This bug is used for discussion on RFP 158 - Distributed Eventing. The actual RFP can be found as an attachment.

Attached file: rfp-0158-DistributedEventing.pdf (application/pdf, 224203 bytes)
Description: RFP 158 - current draft

from design.

Comment author: Scott Lewis <[email protected]>

Some very high level (VHL) comments about the RFP:

1. Would it be desirable to call it 'Remote Events' rather than 'Distributed Eventing'? If for no other reason, than to be consistent with 'Remote Services'

2. I think there should be more discussion about the technical/app requirements around two very important areas for 'group'-based (aka pub/sub) models: reliability and ordering. Related to both is failure detection and group membership. I understand it's early in the RFP process, and so this isn't at all a criticism of what's there. I just think that those two technical areas are the key for defining a programming model for inter-process event delivery in a way that can cover a reasonably large number of use cases...as well as scale effectively.

3. I would suggest adding some Use Cases (section 4) having to do with a) very large-sized groups (e.g. large games, broadcast, many clients [devices] receiving and/or participating) and b) very high bandwidth distribution (i.e. streaming data) or c) both. In other words, emphasize through use cases the positive scalability properties of asynchronous messaging/eventing.

4. RFP 132 is mentioned as the standardization effort around Asynchronous Services. Does this exist in any form yet? FWIW, ECF has been doing this in our own implementation of Remote Services for some time...for explanation see: http://wiki.eclipse.org/ECF/Asynchronous_Remote_Services and http://eclipseecf.blogspot.com/2010/04/osgi-remote-services-and-ecf.html

Hopefully some of what is present...and the people responsible for it...can help inform the work on RFP 132.

5. One of the things that is discussed in the RFP is 'Hybrid Interactions and Contracts'. One comment about this: wouldn't it make sense to use some combination of a) OSGi Services; and b) OSGi Capabilities to express/implement a 'contract'?

6. The notion of a 'data transfer object' seems very similar to a concept that we have underneath much of ECF...of a 'shared object'. Specifically, we have a 'shared object API' that is based upon reliable group communication and object state replication and synchronization. It's the basis of several remote service providers as well as other parts of ECF...e.g. the real-time shared editing/operational transformation.

from design.

Comment author: @bjhargrave

Comment on attachment 56
RFP 158 - current draft

Latest RFP document is now in github: https://github.com/osgi/design/raw/master/rfps/rfp-0158-DistributedEventing.pdf

from design.

Comment author: @bosschaert

Hi Scott,

Thank you for your feedback. Your suggestions were discussed at the EEG face-to-face meeting this week. I'm providing some responses here:

(In reply to Scott Lewis from comment BZ#1)

1. Would it be desirable to call it 'Remote Events' rather than 'Distributed
   Eventing'? If for no other reason, than to be consistent with 'Remote
   Services'

While the EEG is open to renaming the ultimate specification, there was no clear agreement on what the ultimate name would be. So the decision was that we'll leave the name as is for now and revisit when we are closer to finalizing the specification.

2. I think there should be more discussion about the technical/app
   requirements around two very important areas for 'group'-based (aka pub/sub)
   models: reliability and ordering. Related to both is failure detection and
   group membership. I understand it's early in the RFP process, and so this
   isn't at all a criticism of what's there. I just think that those two
   technical areas are the key for defining a programming model for
   inter-process event delivery in a way that can cover a reasonably large
   number of use cases...as well as scale effectively.

There will definitely be more discussion about these topics during the RFC stage. For the RFP it seems that the reliability and ordering fall under 'QoS' and are covered in requirement DE030, DE040, DE042, DE045 and DE047.
I added DE048 to cover failure detection (thanks for spotting that one!). You can see this update on github here: https://github.com/osgi/design/tree/master/rfps
Let us know if this doesn't fit with your views.

3. I would suggest adding some Use Cases (section 4) having to do with a)
   very large-sized groups (e.g. large games, broadcast, many clients [devices]
   receiving and/or participating) and b) very high bandwidth distribution
   (i.e. streaming data) or c) both. In other words, emphasize through use
   cases the positive scalability properties of asynchronous messaging/eventing.

Would you be able to provide such use cases please?

4. RFP 132 is mentioned as the standardization effort around Asynchronous
   Services. Does this exist in any form yet? FWIW, ECF has been doing this
   in our own implementation of Remote Services for some time...for explanation
   see: http://wiki.eclipse.org/ECF/Asynchronous_Remote_Services and
   http://eclipseecf.blogspot.com/2010/04/osgi-remote-services-and-ecf.html

Hopefully some of what is present...and the people responsible for it...can
help inform the work on RFP 132.

Yes there is a desire to restart RFP 132. Hopefully this will happen soon.

5. One of the things that is discussed in the RFP is 'Hybrid Interactions
   and Contracts'. One comment about this: wouldn't it make sense to use
   some combination of a) OSGi Services; and b) OSGi Capabilities to
   express/implement a 'contract'?

Yes, we should look at this during the RFC stage.

6. The notion of a 'data transfer object' seems very similar to a concept
   that we have underneath much of ECF...of a 'shared object'. Specifically,
   we have a 'shared object API' that is based upon reliable group
   communication and object state replication and synchronization. It's the
   basis of several remote service providers as well as other parts of
   ECF...e.g. the real-time shared editing/operational transformation.

Great! Thanks for the pointers :)

from design.

Comment author: [email protected]

Is it still under discussion or relevant in any way? 9 years passed already... https://promocode.com.ph/

from design.