If it is an additive extension, one place to host it is Apache DeltaSpike. It will provide greater visibility. I can help connect if helpful.
Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- From: "Mihai A." <amihaiemil@xxxxxxxxx> Date: 2/3/20 10:31 AM (GMT-08:00) To: jsonp developer discussions <jsonp-dev@xxxxxxxxxxx> Subject: Re: [jsonp-dev] AbstractJsonObject and AbstractJsonArray
Sure, I've thought of that. I've even started my own implementation of JSON-P some time ago. But it's such a simple feature that I figured it would benefit everyone a lot.
Best regards, Mihai
In the worst case, perhaps you could explore publishing the enhancement as an external third party library if it is indeed non-breaking/additive.
Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- Date: 2/3/20 10:08 AM (GMT-08:00) Subject: Re: [jsonp-dev] AbstractJsonObject and AbstractJsonArray
Hi Mr. Rahman,
Thank you for your feedback. I'd just like to say that this feature seems very substantial to me, in the fact that users can implement their own JsonObject and JsonArray much easier.
It's not a feature for library itself -- as I said in the comments, it's not for the JSON-P providers to extend, it's for the users. Well, maybe JSON-P providers could also extend them to provide richer implementation of JsonObject/Array, but it is certainly not mandatory and not breaking in any way (Mr.Kornilov said it's a breaking change, but it's not).
I'd also like to ask everyone in this mailing list to state their opinions. And please, don't just use emojis to show support or denial - I'd like to see comments, pros and cons.
Best regards, Mihai
I am personally unsure what to think of this but want to give it the benefit of the doubt. Dmitry is understandably skeptical as this shifts existing API paradigms and does not really add substantial feature capabilities as far as I can see.
I would also request that other users and committers weigh in. Besides, I think it is time we spun up some conversations around Jakarta EE API development.
Reza Rahman Jakarta EE Ambassador, Author, Speaker, Blogger
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- Date: 2/3/20 1:49 AM (GMT-08:00) Subject: [jsonp-dev] AbstractJsonObject and AbstractJsonArray
Hi all,
I was told I had to open a discussion in this mailing list, in order for my Feature Request to be accepted.
I am a strong advocate for Object-Oriented Programming and I believe these 2 classes (AbstractJsonObject and AbstractJsonArray) are needed in order to help the user implement their own JsonObject and JsonArray where needed. See the JavaDocs in the PR, for examples of usage. I personally implement my own JsonObject/JsonArray quite often.
Furthermore I believe these classes should reside in the API because they are provider-agnostic. I believe the API should implement as much provider-agnostic functionality as possible.
Please, let me know what you think, or comment on the Pull Request or its corresponding Issue.
Best regards, Mihai
jsonp-dev mailing list
jsonp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jsonp-dev
--
jsonp-dev mailing list
jsonp-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jsonp-dev
--
|
