[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087261#comment-17087261
]
Noble Paul commented on SOLR-14414:
-----------------------------------
bq.think if you polled the user community rather than the developer community,
job, they would explain that they would prefer the UI live in the project.
The users community does not care where the codebase lives, the developers do.
We pay the price .
bq.There is already a UI. I am simply replacing it with updated code.
You are proposing to add 131 new files. It does not matter whether it is
done by deleting the old files or not.
bq.The fact that the community lacks UI expertise is based on the choice of who
is a part of the community?
Atleast we know who is the community. In the future Solr may become a front-end
GUI app. Atleast, we should consciously make that choice. I, for one, do not
believe that is the right direction we should take. I'm sure there are others
too.
bq.Both of your responses seem to be focused on you and your needs as
developers and Solr committers/experts,
NO. We clearly said that it is possible to have a new UI shipped with Solr. Do
the users care if the code lives inside the Solr codebase? I don't think so. We
have probably 100+ different libraries shied with Solr. Should we add that code
to Solr codebase? No, we don't
I have not seen a single justification on why we should have this code inside
our codebase other than your desire to do so.
> New Admin UI
> ------------
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
> Affects Versions: master (9.0)
> Reporter: Marcus Eagan
> Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
