RFP 158 Distributed Eventing

[bjhargrave]

Original bug ID: BZ#168 From: @bosschaert Reported version: unspecified

[bjhargrave]

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

[bjhargrave]

Comment author: Scott Lewis <slewis@composent.com>

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.

[bjhargrave]

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

[bjhargrave]

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 :)

[bjhargrave]

Comment author: knight4553kai@gmx.com

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