I appreciate the vote for Kotlin Jan! I hadn’t really thought about the argument that if our base is primarily Java centric devs, that Kotlin versus React might be an easier route….
> On Jul 16, 2024, at 11:56 PM, Christos Malliaridis <c.malliari...@gmail.com> > wrote: > > Thanks for your reply too, Jan. You mention important points. > >> If frontend devs are to maintain it and we want to attract frontend > professionals, then stick to industry standard React or similar. > > This is something that troubled me a lot. Following the industry-standards > would probably be the safest path. But getting new frontend developers may > also be challenging and would probably limit their contribution to only the > frontend, which is why I think focusing on the current maintainers > would be safe > alternative too. > >> I did Swing programming, which is hopefully far from what Compose offers > > I also developed a UI with Swing a couple years ago, and I am glad Compose > does things different. > >> I like the simplificy of the current UI > > I was surprised when I saw it. I think it will be difficult to achieve > similar results in simplicity with modern frameworks. > >> I'd like for the UI to be served by a separate servlet/backend that acts > as a proxy, so that the Admin UI could be installed separately in a DMZ > network > > This is something I had to give some thought first. I believe that the UI > should be implemented against the API, regardless of the deployment method. > It should probably not be the responsibility of the UI how or where it is > deployed, but it should be flexible enough so that it can work no matter > the environment. I agree that there are probably better ways > (security-wise) to host it, but this is a matter of abstraction and should > be addressed separately (e.g. different environments may use different > proxies). > >> If we managed to separate the new UI as an independent servlet, perhaps > with its own /login logic, it would be so much easier to later move the > entire UI to a separate repo, should the need arise. > > I think it's already quite easy to deploy the UI outside or move the source > code to a separate project thanks to Gradle modules and the API > abstraction. My thoughts from above apply here too and this proxy could be > addressed while the new UI is under development (e.g. in combination with a > desktop client for example). > >> just skip the "new" keywork and semicolons, hehe > > That's a great way to describe Kotlin to Java devs. :D > On Mon, 15 Jul 2024, 22:39 Jan Høydahl, <jan....@cominvent.com> wrote: > >>> - What technology stack would you consider and why? >>> - Would you consider a web-based / javascript-based framework easier to >> get >>> started with, or a JVM-based / kotlin-based UI framework? >> >> I consider these related. And it boils down to who will maintain the Admin >> UI app. >> If frontend devs are to maintain it and we want to attract frontend >> professionals, then stick to industry standard React or similar. >> However, for the lifetime of the project it's been Java devs who have >> maintained the UI with a few huge re-writes being the exceptions, but those >> were mostly one-offs or at least one-person. >> >> So I see why you propse the Kotlin based Compose. In a previous life in >> the 90's with Java 1, I did Swing programming, which is hopefully far from >> what Compose offers, which I know nothing about. >> >>> - What was your experience so far with Solr's UI code? What would you >> avoid >>> doing again, what did you like before? >> >> I helped patch both the jQuery and the Angular UI. Notable contributions >> include the OIDC auth impl, the Nodes screen and the ZK Status page. >> On one side I like the simplificy of the current UI, just some JS/HTML/CSS >> files, not build, compiling etc. >> On the other hand, it makes it hard to add 3rd party modules, upgrade libs >> etc. >> I dislike the fact that the UI is hosted by the main Solr process and >> talks directly to Solr backend APIs. I'd like for the UI to be served by a >> separate servlet/backend that acts as a proxy, so that the Admin UI could >> be installed separately in a DMZ network and poke a hole in firewalls >> between the AdminUI's own backend and the Solr cluster (which would be on a >> secure inner network). >> >> If we managed to separate the new UI as an independent servlet, perhaps >> with its own /login logic, it would be so much easier to later move the >> entire UI to a separate repo, should the need arise. >> >>> - Would you be interested in contributing to the UI implementation? >> >> I could probably lend a helping hand here and there, do some reviews, and >> if we manage to partition the elephant, pick a few tasks further down the >> road. >> >> I do Kotlin in day job, and it is an absolute joy to work with. Not hard >> at all, so to committers fearing a "new" language, it is actually not that >> different, just skip the "new" keywork and semicolons, hehe. >> >> Jan Høydahl >> >>> 15. juli 2024 kl. 15:49 skrev Christos Malliaridis < >> c.malliari...@gmail.com>: >>> >>> 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 >>>> >>>> >> _______________________ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
