Hi Kevin,
See my answers inline.
Regards,
Aleks
Hi,I was just reviewing the material for this new Jakarta RPC spec project proposaland I see that the Creation Review processhas been initiated, with conclusion by Nov 24. We have several comments that I would like to ensure that our wider Spec Committee can participate on. (Providing comments on the proposal itself or the creation review record seem to get "lost" and most people do not see them.)First off, the overall content and direction of the Jakarta RPC project proposal seems sound. Creating a Specification based on the gRPC programming model is a good step forward. But, ...
- The name of the project is confusing. I'm afraid it would be very easy to confuse Jakarta RPC with JAX RPC, and it's my understanding that this Spec is not a reincarnation of JAX RPC. From the associated issue, it seems that Jakarta gRPC is also not acceptable since "gRPC" is already trademarked. Since gRPC is based on "protocol buffers", maybe we should be more verbose and call it "Jakarta Protocol Buffering RPC" or "Jakarta pRPC", for short. Just an idea. But, I think we need to do something other than "Jakarta RPC".
Mentioning Protocol Buffers explicitly is wrong, when one of the goals of the spec is to make it easier to use gRPC *without* ProtoBuf. gRPC itself is marshaller agnostic, and allows you to specify a different marshaller (if you really want to) for the request and response payloads for every single method. It is in no way tied to ProtoBuf
at the architectural level.
What makes it tied to it at the moment is the tooling and the lack of documentation on how to support other formats. The spec we are proposing eliminates the need for tooling, for the most part, and makes it very easy to support any serialization format.
However, that does leave us in a bit of a limbo when it comes to the name… The two latest proposals were "Jakarta RPC" and "Jakarta for gRPC", and I guess Maria Teresa renamed the creation review issue to reflect the first option. I just posted a comment asking if a bit longer name of "Jakarta API for gRPC Services” would work, as I really see this spec as a gRPC equivalent of JAX-RS (Jakarta API for RESTful Web Services), and was at one point even proposing JAX-gRPC. Unfortunately, trademarks, both Oracle’s and CNCF’s do not make this easy… :-(
I do agree though that Jakarta RPC does not make it obvious enough that this spec focuses on gRPC, and implies other RPC frameworks may or should be supported, which is not where we want to go, imo.
- The initial set of committers is too single vendor heavy. When we first created all of the Jakarta Specification Projects, we enlisted two reps from each strategic member plus other interested parties for the initial set of committers. This helps diversify the community and provides some balance to the direction of the project. I'd like to see us go back to those roots and encourage/enlist participation by other strategic members and limit the number of initial committers from any one organization. To that end, IBM would like to put forth two names to participate on this spec project -- Bill Lucy and Paul Niccoluci. (FYI, Bill would even be interested in co-leading the project, if Aleksander is looking for any assistance.)
This is just a consequence of the fact that we are proposing something we’ve built as part of Helidon for standardization, so I only added the people who have worked on the original design and implementation as committers.
I’m certainly happy (actually, hoping) to add contributors from other orgs, including Bill and Paul, and to have a chat with Bill to discuss whether it makes sense to add him as a lead. Personally, I’m happy to share the burden, especially with someone who is likely more familiar with the Jakarta processes than I am, but I want to make sure we are in agreement at least at the high level, as once again, what we are proposing is largely a derivative of something we’ve already built.
I would suggest that anyone interested watches
the recording of the Jakarta Tech Talk I did on Tuesday, and then we can have a more informed conversation on contributors, leads, etc. In the meantime, I’ll add both Bill and Paul to the proposal, under the assumption that they will still want to help, even after watching me for 50 minutes or so ;-) I just need their
Eclipse.org emails.
- Once a diverse set of initial committers is identified, then the selection of the patent license could be determined. I know that Oracle took the initiative to create this project proposal (thank you!) and they would prefer the CPL license, but once we get more participation from the wider pool, would CPL still be the desired patent license? With all of the initial participants coming from one organization, I think it sways the selection of the patent license. As was done with the Config spec project, having an informal vote from the eventual diverse membership would produce a better view of the desired patent license.
I really have no comment on this one. I’ll leave it at that… ;-)
Thanks!
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
