Thanks for the references David, those are very insightful to me. I am definitely not the first one coming up with these ideas, that's for sure.
I think the fact that there are multiple third-party frontends for Solr shows how important the UI is to the users and it should push us even more to do something about the current state. *If there is no objection about the proposed approach I would like to proceed and discuss the technology stack that could be used and fulfill our current requirements.* As I already mentioned before, I've been working on a proof-of-concept with Compose Multiplatform (Kotlin) that demonstrates what an integration would look like. Since there are many pros and cons for all the available UI frameworks out there, I broke down my point of view and reasons for Compose in a writeup <https://docs.google.com/document/d/17B6TuUbbpvg823ixrsnVPT6hJ4vuVv9UHzIz4jITvHI/edit?usp=sharing> again. But because this is a very opinionated topic, *your input is needed*. To be more precise, here are a few questions: - What technology stack would you consider and why? - What was your experience so far with Solr's UI code? What would you avoid doing again, what did you like before? - Would you be interested in contributing to the UI implementation? - Would you consider a web-based / javascript-based framework easier to get started with, or a JVM-based / kotlin-based UI framework? Best, Christos On Fri, Jul 12, 2024 at 11:39 PM David Smiley <dsmi...@apache.org> wrote: > An admin UI can definitely be plugged in. Here is one: > https://github.com/yasa-org/yasa > And you would not be the first to consider a desktop client. There is > one of those too: https://solr.search-navigator.org/ > > On Tue, Jul 9, 2024 at 9:37 PM Christos Malliaridis > <c.malliari...@gmail.com> wrote: > > > > Thanks for your input, votes and feedback so far, I appreciate it. > > > > The security concerns are justified and are something I am currently > > looking into. With a rewrite it will be easier to take that into account > > and consider alternative options that could also enhance security, too. > For > > example, I am experimenting with a JVM-based and standalone desktop > client > > (that is probably a safer option and provides extended authentication > > support) that can also be run alongside the current Admin UI as a > > WebAssembly app if needed (see changes in > > https://github.com/malliaridis/solr/tree/composeui). Another option I > was > > considering was to write and provide the UI as a Solr plugin, but I am > not > > sure if this could work with the current way plugins are loaded. > > > > So in my opinion and alongside the current concerns like maintenance of > UI > > code, this might be solvable with the right technology selection and API > > implementation (which would be follow-up topics). > > > > On Tue, Jul 9, 2024 at 10:57 PM Gus Heck <gus.h...@gmail.com> wrote: > > > > > Disabling certainly is helpful, but... there's the risk it gets > enabled, > > > it will still contribute to the footprint that vulnerability scanners > have > > > to cover. > > > > > > If it's something that can be enabled/disabled or removed from the full > > > distro, and added to the slim distro if desired, that would be even > better. > > > The easier all of those things are, the better of course. > > > > > > Food for thought: https://github.com/jetty/jetty.project/issues/5007 > > > > > > If the UI is a self contained web-app containing only JS/HTML that can > be > > > undeployed that's pretty much a standards based solution to the > problem. > > > This sort of wheel was invented long long ago, and we have the basic > tools > > > at our disposal already (jetty)... There is no need for the UI to have > any > > > java code at all I suspect... > > > > > > -Gus > > > > > > On Tue, Jul 9, 2024 at 3:20 PM David Smiley <dsmi...@apache.org> > wrote: > > > > > > > RE security; disabling it would suffice and if I recall is already > > > > supported. > > > > > > > > On Tue, Jul 9, 2024 at 3:09 PM Gus Heck <gus.h...@gmail.com> wrote: > > > > > > > > > > Also +1 ... "in the same repo and alongside" is how the last > migration > > > > was > > > > > done IIRC. The big plus of this is as it's developed to a point of > > > > partial > > > > > utility you can put a link in the old UI to try out the new UI and > get > > > > > feedback and make testing much easier. > > > > > > > > > > One thing that might be nice if we can do it, is to make the UI > more > > > > > pluggable, and allow those who have no desire to test it to start > solr > > > > with > > > > > it fully uninstalled. (i.e because they don't want to account for > its > > > > > security in production) > > > > > > > > > > Also it would be very good if we carefully understood how we want > to > > > > > achieve security (including information exposure, and role based > > > > > access/display) before we put it in a release. > > > > > > > > > > On Tue, Jul 9, 2024 at 10:40 AM Houston Putman <hous...@apache.org > > > > > > wrote: > > > > > > > > > > > I agree with Jason on everything. > > > > > > > > > > > > Thank you so much for putting this much work into something with > so > > > > much > > > > > > baggage in the community! > > > > > > > > > > > > I'm a huge +1 here, and love the things I saw in your > screenshots on > > > > Slack. > > > > > > > > > > > > - Houston > > > > > > > > > > > > On Mon, Jul 8, 2024 at 2:23 PM Jason Gerlowski < > > > gerlowsk...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Hey Christos, > > > > > > > > > > > > > > Sorry for the delay responding here - lots of context to read > up > > > on! > > > > > > > > > > > > > > Firstly, thanks for the huge effort you've put into writing > this > > > all > > > > > > > up! Quite the thorough job, and it's really helpful to enable > us > > > > > > > non-UI folks to follow along haha. > > > > > > > > > > > > > > If I understand things correctly, there's a few distinct > aspects to > > > > > > > your proposal: > > > > > > > > > > > > > > 1. New UI would live alongside the existing one (for a time) > > > > > > > 2. The code for the new UI would live in the main repository. > > > > > > > 3. Development would be piece-meal (i.e. not one big code-dump) > > > > > > > > > > > > > > Overall, this sounds like a reasonable approach to me. > > > > > > > > > > > > > > I think a big concern with putting code in the main repo is > that > > > it's > > > > > > > pretty far from the (current) PMC's/community's wheelhouse to > > > > > > > maintain. I definitely share that concern. But IMO we're > already > > > > > > > sortof at a "worst case" in that regard with our existing > Admin UI > > > > > > > code. Doing the "refresh" in the main repo gives us a forcing > > > > > > > function (i.e. the review process itself) to ensure that at > least a > > > > > > > few community members will understand the code to at least some > > > > > > > extent. That'll be a huge improvement over where we are today. > > > > > > > > > > > > > > Anyway, I'm a cautious '+1' based on these details at least. > To > > > > quote > > > > > > > a message from Jan in Slack: "I'd rather see some imperfect > > > movement > > > > > > > than a perfect plan never realized." > > > > > > > > > > > > > > (Here's hoping my reply will bump this to the top of folks' > > > Inboxes, > > > > > > > and get you some more feedback.) > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Jason > > > > > > > > > > > > > > On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis > > > > > > > <c.malliari...@gmail.com> wrote: > > > > > > > > > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > In regards to SIP-7 > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI > > > > > > > > > > > > > > > > and SIP-10 > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience > > > > > > > > > > > > > > > > I would like to add my perspective and address the current > > > concerns > > > > > > about > > > > > > > > implementing a new UI, so that we can take some actions and > > > > improve the > > > > > > > > overall quality and experience of Solr Admin UI. > > > > > > > > > > > > > > > > There are many discussions and opinions about the UI and how > to > > > > resolve > > > > > > > the > > > > > > > > current issues, but they all led to the topic becoming > stale. In > > > my > > > > > > > > opinion, developing and introducing a new UI into the main > > > > repository > > > > > > > piece > > > > > > > > by piece without replacing the current UI until > feature-complete > > > > could > > > > > > > > > > > > > > > > - address all the issues currently reported (and not), > > > > > > > > - add new features, > > > > > > > > - replace the EOL framework and > > > > > > > > - improve the overall user experience. > > > > > > > > > > > > > > > > And the maintenance, which is one of the most important > parts, > > > > could be > > > > > > > > addressed with the right choice of framework. > > > > > > > > > > > > > > > > I created a detailed writeup > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing > > > > > > > > > > > > > > > > for those who are interested, where I also write about the > > > > alternative > > > > > > > > approaches proposed in the past and listing the pros and > cons of > > > > each > > > > > > one > > > > > > > > individually. > > > > > > > > > > > > > > > > I also started to improve this part by simply designing a > new UI > > > > > > > > < > > > > > > > > > > > > > > > > > > > > > https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept > > > > > > > > > > > > > > > > and addressing multiple issues at once. I have already > received > > > > some > > > > > > > community > > > > > > > > feedback > > > > > > > > < > > > > https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999 > >, > > > > > > > but > > > > > > > > it is far from production-ready and needs more input. I think > > > this > > > > > > could > > > > > > > be > > > > > > > > further refined and moved to development if there is > consensus on > > > > that > > > > > > as > > > > > > > > the initial approach. > > > > > > > > > > > > > > > > What's your opinion about this approach and do you have any > > > > concerns > > > > > > that > > > > > > > > have not been addressed? > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Christos > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > > > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://www.needhamsoftware.com (work) > > > > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > > > > > -- > > > http://www.needhamsoftware.com (work) > > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
