Comments (5)
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:
-
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'
-
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.
-
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.
-
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.
-
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'?
-
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)
- 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.
- 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.
- 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?
- 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.htmlHopefully 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.
- 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.
- 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.
Related Issues (20)
- Ordering issue with RFC-217 "osgi.jaxrs.filter.base" filters HOT 2
- rfc-217 should clarify how ApplicationPath annotation can affect the base path HOT 1
- RFC-217 support for Feature, DynamicFeature, ContextResolver and other providers HOT 3
- RFC-221 Transaction control: Release resources managed by JDBCConnectionProvider HOT 4
- Typos in RFC 221 Transaction Control - Drafs HOT 1
- RFC-229 MQTT Wildcard topics HOT 2
- [Converter] Conversion of Collections HOT 2
- R7 Core draft 2017-3, 10.8.4.3 (Capability and Requirement version params) HOT 2
- Configurer specification - partial configurations and merging (R8+) HOT 2
- Feature: support Optional<T> for DS service reference type HOT 3
- [RFC 216/ PushStream] Inconsistency between JavaDoc/Spec Section 706.7.14.6 and the reference implementation HOT 1
- [RFC 216/ PushStream] Inconsistent time unit of PushbackPolicyOption.getPolicy() between JavaDoc and implementation HOT 4
- Component "outjection" for declarative services. HOT 1
- rfc-241 (Feature) - json structure and comment HOT 4
- Offer BundleContext#registerService without HashTable HOT 4
- [JPA Service] allow a JPA Service to use the (non-)jta-data-source attribute instead of the javax.persistence.jdbc.driver property HOT 1
- DS 1.4 Component Property Types: Allow meta annotations or static fields for generating constant component properties HOT 3
- DS 1.4 Component Property Type Annotations: Allow elements which only optionally create component properties HOT 1
- DS: Allow a condition towards a framework property HOT 3
- DS: Allow conditions for a class being available to the classloader HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from design.