+1 for Kotlin; I've used it in the past and was fond of the experience. I'm sad we don't use it in our Gradle files. But take this with a grain of salt: I don't *intend* to work on the UI to be honest so my opinion of the tech there doesn't matter much. I suppose I might end up touching it if I work on something that the UI exposes.
On Wed, Jul 17, 2024 at 3:37 AM Eric Pugh <ep...@opensourceconnections.com> wrote: > > 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
