+1 to David Smiley On Sat, Apr 11, 2020, 8:12 AM Marcus Eagan <marcusea...@gmail.com> wrote:
> I don't see admin UI as non-core. I think that an application UI for > end-users of an application consumes Solr non-core. I have to resign from > arguing, though. > > I don't consider myself a UI expert. I can do the work. > > > On Fri, Apr 10, 2020 at 11:42 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> David, you capture my thoughts well. >> >> Having a UI as a package gives users more choice and gives our users more >> flexibility. >> 1. Users would be able to use a latter version of the UI with an older >> version of Solr, or vice versa. >> 2. Users should be able to install multiple types of UI, from different >> publishers, at once. >> 3. Contributors should be able to contribute to the UI more easily, since >> collaboration can be less bureaucratic. Experts like Marcus won't need to >> depend on preoccupied committers like us. >> 4. A UI (not the default one) can use libraries that aren't even Apache >> 2.0 compatible. >> 5. We can setup and use UI test frameworks for test automation (selenium >> etc), that would be challenging to setup and maintain with ASF Jenkins. >> >> List goes on.. >> >> Whether the package is a first party or third party can be a separate >> discussion. There should be an extremely easy and well defined way (support >> in the script itself) to start Solr with the packaged UI enabled. >> >> In any case, I don't think it is conducive to let UI code be part of the >> Solr's core codebase, where it currently is. The reason is, we can't fix >> bugs if we break something. We don't have automated testing either to know >> whether or not we broke anything. >> >> Every healthy project has a rich plugin ecosystem, and such non core >> improvements should be delivered via packages. >> >> On Fri, 10 Apr, 2020, 8:33 pm Marcus Eagan, <marcusea...@gmail.com> >> wrote: >> >>> I agree with you. đ >>> >>> On Fri, Apr 10, 2020 at 06:22 David Smiley <david.w.smi...@gmail.com> >>> wrote: >>> >>>> I disagree that "package management frameworks are for loading >>>> non-essential features or features not enabled by default". >>>> >>>> I don't think the proposal of the UI being a "package" (in the new >>>> package system) implies that the UI (or _any_ package) is not a >>>> highly valuable package that is so highly valuable that we want it >>>> installed by default. Noble and I were brainstorming on some ideas where >>>> even much of Solr's internal instances of plugin interfaces (e.g. query >>>> parsers, etc.) might even be a new "core" package or some-such. The value >>>> in putting much of Solr in a package, 1st party, is separation of concerns. >>>> and better classpath management. >>>> >>>> I think it's "essential" that a UI ship with Solr by default -- >>>> meaning, without the user having to take any additional steps whatsoever. >>>> As Jan said it's been this way a long time. >>>> >>>> ~ David Smiley >>>> Apache Lucene/Solr Search Developer >>>> http://www.linkedin.com/in/davidwsmiley >>>> >>>> >>>> On Fri, Apr 10, 2020 at 1:35 AM Marcus Eagan <marcusea...@gmail.com> >>>> wrote: >>>> >>>>> I think package management frameworks are for loading non-essential >>>>> features or features not enabled by default. On essentialness, experts >>>>> should not decide what is essential based on how they use a system. They >>>>> should consider the community of users. Regarding UI, it is and should be >>>>> enabled by default. Only a few use cases prefer it to be disabled and some >>>>> of those are because of its current state. They would like to use it in an >>>>> updated form. >>>>> >>>>> What is the technical rationale that outweighs the needs and behaviors >>>>> of our users to strip the user interface out of Solr? >>>>> >>>>> Thank you Noble and everyone else, >>>>> Marcus >>>>> >>>>> >>>>> On Thu, Apr 9, 2020 at 19:06 Noble Paul <noble.p...@gmail.com> wrote: >>>>> >>>>>> My 2 cents (again) >>>>>> >>>>>> if packages are disabled by default , how will UI work? >>>>>> >>>>>> We can make an exception for this one and enable only this by default >>>>>> >>>>>> Do we test the UI and certify it? >>>>>> >>>>>> The UI package can be shipped along with Solr distro ,like the million >>>>>> other jars that we ship with Solr today and every version of Solr can >>>>>> be certified for a certain version of the UI package. We should have >>>>>> sanity tests to ensure that the given version of UI works well with >>>>>> Solr. "My commit has broken the UI and it's not my problem" should not >>>>>> be a valid excuse. The UI sanity tests should pass as a part of the >>>>>> tests. >>>>>> >>>>>> Is the UI important? >>>>>> >>>>>> Yes, the admin UI is the face of Solr for may users. People always >>>>>> assumed it existed & they depend on it. >>>>>> >>>>>> The current admin UI has fallen behind. If the new UI effort delivers >>>>>> on the promise, this is a great opportunity to get rid of that old >>>>>> baggage & make Solr codebase even slimmer >>>>>> >>>>>> On Fri, Apr 10, 2020 at 6:06 AM Jan Høydahl <jan....@cominvent.com> >>>>>> wrote: >>>>>> > >>>>>> > Solr has always had an admin UI and if anyone wants to propose it >>>>>> should not, please start another thread or vote about that, and do not >>>>>> divert this thread which is about how to improve and future proof the >>>>>> Admin >>>>>> UI. >>>>>> > >>>>>> > I believe the Admin UI should be strengthened and enhanced, not >>>>>> removed. It can perfectly well be an official and even default on part of >>>>>> every release, perfectly in sync. Whether it is in core as today or a >>>>>> package or a stand-alone process or a new webapp, are then really what we >>>>>> discuss here. >>>>>> > >>>>>> > Perhaps after people have voiced their opinions in this thread, a >>>>>> SIP can be crafted with a concrete plan. We can then have a vote on the >>>>>> SIP. >>>>>> > >>>>>> > Jan Høydahl >>>>>> > >>>>>> > > 9. apr. 2020 kl. 20:06 skrev Cassandra Targett < >>>>>> casstarg...@gmail.com>: >>>>>> > > >>>>>> > > ďťż >>>>>> > > Thanks for your message, Gus. You touched on things I was >>>>>> thinking this morning as I caught up to the thread, and had started to >>>>>> draft a message about. >>>>>> > > >>>>>> > > I feel like there is an assumption underlying some of our >>>>>> discussion about packages that says a feature or whatever has to either >>>>>> part of our core codebase or 100% maintained by someone âoutsideâ the >>>>>> community (by which I mean someone who is not a committer and/or operates >>>>>> completely independently from the rest of the project activities). >>>>>> > > >>>>>> > > But itâs important to remember thereâs nothing inherent in the >>>>>> package concept that says a package can't be wholly >>>>>> maintained/distributed/supported by the Lucene PMC and our community of >>>>>> committers and contributors. Itâs not uncommon for software to have a >>>>>> base >>>>>> package of the core software and also plugins that most users would >>>>>> consider âessentialâ, maintained by the same people making the core, but >>>>>> which are added after the base install. There would be details to work >>>>>> out >>>>>> in terms of how we manage that, but none of those are technically >>>>>> impossible. I donât think we only have a binary choice (3rd party package >>>>>> or part of Solr core). >>>>>> > > >>>>>> > > In fact, Iâd go so far as to say I suspect the only way packages >>>>>> are going to see any real traction is if we take the lead in creating and >>>>>> maintaining a few to show the way forward for everyone else who may be >>>>>> interested in doing the same. The package concept introduces an idea of a >>>>>> Solr ecosystem that has not really existed to date and like all new >>>>>> ecosystems (communities), it needs some degree of nurturing to grow or it >>>>>> will not take off. >>>>>> > > >>>>>> > > To bring it back around to the UI, though, I agree we need to >>>>>> decide: is a UI important? I would argue that it is. I regularly talk to >>>>>> users whose Solr knowledge and experience are quite advanced yet who >>>>>> still >>>>>> rely entirely on the UI to carry out basic tasks. Itâs just easier - less >>>>>> to remember, donât need to look up a command, etc. Persistent problems >>>>>> with >>>>>> performance of the UI in large clusters and gaping holes in functionality >>>>>> are deeply frustrating to those users. >>>>>> > > >>>>>> > > Because it is important to our users, even if any new UI ends up >>>>>> living outside our community, it will need our explicit approval in some >>>>>> form or weâre going to hear complaints until the end of time that Solr >>>>>> doesnât have a UI (or worse, we âtook awayâ the UI). Without our ongoing >>>>>> endorsement and blessing it will just be another toy maintained by >>>>>> âsomebodyâ (no offense, Marcus) until he is forced to abandon it due to >>>>>> lack of user interest and/or lack of personal time to do all the heavy >>>>>> lifting by himself. >>>>>> > > >>>>>> > > Cassandra >>>>>> > >> On Apr 9, 2020, 11:32 AM -0500, Erick Erickson < >>>>>> erickerick...@gmail.com>, wrote: >>>>>> > >> Gus: >>>>>> > >> >>>>>> > >> Very thoughtful post. I think you raise an _extremely_ important >>>>>> point about âhow critical is the UI?â And by extension other packages. If >>>>>> theyâre critical to Solr, the question of how to keep them in sync >>>>>> becomes >>>>>> paramount. >>>>>> > >> >>>>>> > >> I agree that the admin UI is important, if we have a mechanism >>>>>> to insure itâs kept in sync with the release that would be near the to of >>>>>> my list. >>>>>> > >> >>>>>> > >> Best, >>>>>> > >> Erick >>>>>> > >> >>>>>> > >>> On Apr 9, 2020, at 12:06 PM, Gus Heck <gus.h...@gmail.com> >>>>>> wrote: >>>>>> > >>> >>>>>> > >>> In my view this brings us up against a bit of an existential >>>>>> question. How do we ensure quality of packages that are key to Solr? I'm >>>>>> sure that there are folks who don't find the UI very useful, but it's >>>>>> important to others. The rationale that "elastic keeps their's separate" >>>>>> has to be tempered by the actual real differences between Elastic and >>>>>> Solr. >>>>>> Elastic has a corporate sponsor, a coordinated road map, and explicitly >>>>>> ensures that all the bits that are maintained separately work together >>>>>> (so >>>>>> that they don't have excessive support costs or bad first experiences >>>>>> that >>>>>> impact their bottom line etc.). >>>>>> > >>> >>>>>> > >>> Solr is in a different place however, and we need to carefully >>>>>> examine the question of whether something that works for Elastic works >>>>>> for >>>>>> us. Lucidworks and several other large companies do spend a lot of money >>>>>> on >>>>>> developers that contribute to Solr, but there is no organization around >>>>>> multiple components that MUST work together. Another example of this is >>>>>> Solr and Lucene, and our defense against a lack of coordination of >>>>>> components in that case has been to unify them into a single release >>>>>> package. >>>>>> > >>> >>>>>> > >>> So IMHO we need to answer 2 questions: >>>>>> > >>> 1.) Do we consider the UI important. If I'm alone or in a >>>>>> minority in feeling it's important, then so be it and it doesn't really >>>>>> matter what we do. (maybe a vote?) >>>>>> > >>> 2.) If we make it "a package" how do we ensure that important >>>>>> packages such as the UI are never broken by a new release. >>>>>> > >>> >>>>>> > >>> IMHO I don't thing we should tolerate a situation where things >>>>>> we consider important are broken frequently. >>>>>> > >>> >>>>>> > >>> For my part obviously my answer to 1 is "yes" :). As for 2, one >>>>>> thing that comes to mind is what the Ant project did (may still do?) with >>>>>> (and my memory from 15 years ago is foggy here, so forgive me if >>>>>> something >>>>>> I say is not quite perfect) the GUMP build server that ran ant builds >>>>>> for a >>>>>> bunch of different projects that depended on ant to ensure early >>>>>> detections >>>>>> of changes that would break existing projects. If we have a good UI test >>>>>> suite and commit to that being part of the release build package that >>>>>> might >>>>>> be a solution. I honestly don't actually care where it lives, but I do >>>>>> think it hurts us if it becomes broken and unusable, or hard to install. >>>>>> > >>> >>>>>> > >>> My worry is that "Solr developers are not UI developers" is >>>>>> really code-words for "I want to be able to break it and let others clean >>>>>> up the mess, because I'm not a UI developer". I have this worry with >>>>>> respect to all "packages", but I may be missing info from discussions >>>>>> about >>>>>> the package system, which initiated during a very busy period for me so >>>>>> background links that I should have read are welcome if I've got >>>>>> something >>>>>> wrong here :) I went looking for a SIP but didn't see it... I have found >>>>>> a >>>>>> google doc linked from SOLR-13661 >>>>>> > >>> >>>>>> > >>> Finally to a detail about one of the above suggestions the >>>>>> option to automatically download and install the UI could be good, but >>>>>> that >>>>>> then requires that packages be available from somewhere that never goes >>>>>> away like maven central, or that Apache commits to hosting a repository >>>>>> server indefinitely, but again that's surely been discussed WRT packages >>>>>> already... Using Github in such a way is subject to being broken >>>>>> arbitrarily when Github decides to restrict things for cost reasons (ask >>>>>> Bower about that one WRT rate limiting...) or the "repository" has to be >>>>>> something local and therefore must be included part of the >>>>>> distribution... >>>>>> at which point it's still a thing we distribute and since we're >>>>>> distributing it and we probably don't mean to distribute broken stuff we >>>>>> still need UI developers... >>>>>> > >>> >>>>>> > >>> Also, I thought the package loading stuff was supposed to be >>>>>> disabled by default for security, that seems to conflict with or at least >>>>>> complicate the notion of easily installing as a package. >>>>>> > >>> >>>>>> > >>> So "package" is a good for modularizing code, or for 3rd party >>>>>> (possibly paid) plugins (I have a client that might find that interesting >>>>>> in the future) but we have to ensure that it doesn't lead to a lack of >>>>>> maintenance for things that are critical. >>>>>> > >>> >>>>>> > >>> Incidentally though I've said I favor Angular CLI, >>>>>> (significantly because I've got some start on learning it) it also occurs >>>>>> to me that perhaps anything "modern" is a difficulty because those things >>>>>> all have a learning curve, and maximizing accessibility and ease of >>>>>> modifications for folks not steeped in UI development might be our >>>>>> priority >>>>>> (different from the priorities a commercial site would have). The flip >>>>>> side >>>>>> argument is that with a popular framework, it would be easier for UI >>>>>> focused folks to contribute... but will they? and does that leave us >>>>>> perennially rewriting the UI in whatever is popular? (maybe that's ok?) I >>>>>> think in all our decisions here we need to be very careful to distinguish >>>>>> how our needs may differ in unusual ways from the needs of commercial web >>>>>> development. >>>>>> > >>> >>>>>> > >>> -Gus >>>>>> > >>> >>>>>> > >>> On Thu, Apr 9, 2020 at 8:14 AM Erick Erickson < >>>>>> erickerick...@gmail.com> wrote: >>>>>> > >>> Marcus: >>>>>> > >>> >>>>>> > >>> re-reading the thread, it looks to me like the consensus from >>>>>> Noble and Ishan and Jan is that as long as the new, nifty UI is a >>>>>> separate >>>>>> package, go ahead and knock yourself out ;). The objection is to making >>>>>> it >>>>>> part of the Solr code base⌠Weâll all be thrilled with if we can rip the >>>>>> current admin UI out ;) >>>>>> > >>> >>>>>> > >>> That said, I suspect itâll be one of the tighter packages. Itâd >>>>>> be super-cool if we could run the UI tests on Jenkins say once a day just >>>>>> to keep it up to date. >>>>>> > >>> >>>>>> > >>> The admin UI has always been somewhat awkwardly bolted on the >>>>>> side of Solr, itâd be great to have it have a more elegant architecture. >>>>>> > >>> >>>>>> > >>> The other exciting thing would be that clients could then use >>>>>> the package code as something they can incorporate/fork/whatever. >>>>>> Practically every client Iâve worked with at large installations has >>>>>> rolled >>>>>> their own dashboard. If they could use a package as a starting point, >>>>>> itâd >>>>>> be welcome. >>>>>> > >>> >>>>>> > >>> Best, >>>>>> > >>> Erick >>>>>> > >>> >>>>>> > >>>> On Apr 9, 2020, at 3:07 AM, Marcus Eagan < >>>>>> marcusea...@gmail.com> wrote: >>>>>> > >>>> >>>>>> > >>>> Hey Noble, >>>>>> > >>>> >>>>>> > >>>> -1 is a definitive, so I want to clarify that you are saying >>>>>> you do not wish to remove the EOL front end and replace it with another >>>>>> one >>>>>> in the longer term? >>>>>> > >>>> >>>>>> > >>>> I hear you! As a product manager in my day job, my primary >>>>>> goal is to find features to cut! I spend a lot of time thinking about >>>>>> non-essential vs used heavily vs causes more problems than it's worth. I >>>>>> can tell you from watching the many people in the field at Lucidworks, >>>>>> there are a lot of people who know quite a bit about Solr, but rely on >>>>>> the >>>>>> Admin UI heavily because they feel comfortable there. Those people in >>>>>> effect help us stay employed despite never contributing or being capable >>>>>> of >>>>>> contributing to Solr. So hear me out. I've got a proposal: >>>>>> > >>>> >>>>>> > >>>> To start, I can work on this app as an optional package for >>>>>> your awesome new package manager. It will be the second one I've worked >>>>>> on >>>>>> in my evenings and weekends btw. The first was a package validator that I >>>>>> hope to eventually open source, but its complexity and lack of popularity >>>>>> because it is security ;( will likely make it the second one I open >>>>>> source/finish. I'm also collaborating with a couple members of the >>>>>> Lucidworks security team on that one, but I have built the basics already >>>>>> for them to build upon. >>>>>> > >>>> >>>>>> > >>>> Back to the new UI discussion and my update that I promised. >>>>>> > >>>> >>>>>> > >>>> My update was going to be that after evaluating the projects >>>>>> Jan posted, the most recent project that Jan listed created a pretty good >>>>>> base to build on. After lots of auditing of the packages and a bit of >>>>>> refactoring because the UI world moves fast, I was able to get it to >>>>>> transpile and run again (as I'm sure it previously did) and from (2290 >>>>>> vulns): >>>>>> > >>>> <image.png> >>>>>> > >>>> no npm fix doesn't magically fix, I wish it did >>>>>> > >>>> >>>>>> > >>>> to (2 low sev, non-productions vulns): >>>>>> > >>>> <image.png> >>>>>> > >>>> >>>>>> > >>>> These two issues will not affect production and really only >>>>>> the unit tests. Besides, I plan to remove them before we get to a stage >>>>>> even that matters. I've also started investigating the level of effort >>>>>> for >>>>>> me to get it to feature parity with the current app. The preliminary >>>>>> answer >>>>>> is not very much compared to other work I've done in shorter time â >>>>>> working >>>>>> with a jerk for a boss (years ago, don't worry Hatcher). I'm building a >>>>>> couple of the missing features as we speak. From the beginning, it will >>>>>> have infinitely more test coverage and will be a lot more approachable to >>>>>> contemporary UI developers. It will also make the Solr experience for new >>>>>> developers simpler. The major design changes that I have been thinking >>>>>> about would be to the cloud view and the query view. Both of those are >>>>>> important, the first to more experienced users, and the second to less >>>>>> advanced users though occasionally an advanced debugger or demo presenter >>>>>> in my experience. >>>>>> > >>>> >>>>>> > >>>> In the end Noble, this is about making Solr more approachable >>>>>> to new users not experts like you. The growth of Solr adoption only >>>>>> benefits you, so I would ask you to revisit your -1 at some point in the >>>>>> near future when you see the progress and breadth of improvement. We have >>>>>> had customers complain about the Admin UI and the community has even >>>>>> complained about it. I think this is the right thing to do. If you still >>>>>> consider effectively upgrading the current Admin UI as feature creep, I >>>>>> can >>>>>> revisit the package manager compromise or move the efforts elsewhere. I >>>>>> respect your position. A search service is nothing without a strong and >>>>>> diverse set of skills and capabilities behind it and making it accessible >>>>>> to everyone who needs it. >>>>>> > >>>> >>>>>> > >>>> For those who care, here's my 4 Node cluster of tech products >>>>>> running locally. >>>>>> > >>>> >>>>>> > >>>> <image.png> >>>>>> > >>>> >>>>>> > >>>> The shoulders of the homie that put that scaffold together are >>>>>> broad! Props to him. I will volunteer to put together extensive docs for >>>>>> JS >>>>>> devs who want to contribute and make it better once we get it to a place >>>>>> where it replaces and improves upon the current option. I'll even sponsor >>>>>> some prizes for college kids or people recently out of work to get >>>>>> cranking >>>>>> on this bad boy. >>>>>> > >>>> >>>>>> > >>>> Thank you Noble and everyone else, >>>>>> > >>>> >>>>>> > >>>> Marcus >>>>>> > >>>> >>>>>> > >>>> On Wed, Apr 8, 2020 at 11:20 PM Noble Paul < >>>>>> noble.p...@gmail.com> wrote: >>>>>> > >>>> Solr developers are not UI experts. We are a search service >>>>>> and such a service should have nice clean APIs + documentation. Is a UI >>>>>> useful ? yes. The last thing we want today is another complex component >>>>>> in >>>>>> Solr codebase that nobody understands or cannot maintain. >>>>>> > >>>> >>>>>> > >>>> So, Solr UI can be hosted outside our codebase and we can have >>>>>> an option to install UI from that remote repo >>>>>> > >>>> >>>>>> > >>>> something like "bin/solr install-gui" >>>>>> > >>>> >>>>>> > >>>> I'm -1 on anymore feature creep. >>>>>> > >>>> >>>>>> > >>>> --Noble >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> On Thu, Apr 9, 2020 at 12:22 PM Marcus Eagan < >>>>>> marcusea...@gmail.com> wrote: >>>>>> > >>>> Thanks again Gus. >>>>>> > >>>> >>>>>> > >>>> Lots of people indeed misuse REST so we could go on and on >>>>>> about whether requests are stateless or not in another thread. Let's >>>>>> spare >>>>>> the group. >>>>>> > >>>> >>>>>> > >>>> I think most everyone on this channel would be in agreement >>>>>> with you on separate app. I'll be opening a new ticket and a PR that will >>>>>> document a few things to make it easy for UI devs who know little to no >>>>>> Java how to get started. >>>>>> > >>>> >>>>>> > >>>> Ishan, there's some significant UI expertise in the team. >>>>>> Erickson finds his way to open every cookie jar. Erik Hatcher wrote the >>>>>> first version of Blacklight. I've seen Pugh do lots of work on Quepid's >>>>>> UI. >>>>>> Jan and Kevin have done a lot of work, and so have many others. The list >>>>>> goes on, and *likes to work on UI* is a different discussion. >>>>>> > >>>> >>>>>> > >>>> Beyond committers because I'm not a committer, I have UI >>>>>> expertise that I can polish off and improve for the sake of my interest >>>>>> and >>>>>> commitment to the community and I like to do it. I've also led UI teams. >>>>>> I >>>>>> can help to steward the effort overall and keep things up to date up to >>>>>> the >>>>>> point where I need to ask one of the committers to help me get changes >>>>>> merged. I'll probably even hire a developer to work on it once we are to >>>>>> that point. ;-) >>>>>> > >>>> >>>>>> > >>>> Expertise is not something that should block us but motivate >>>>>> us to expand this community and/or our own skillsets long term. >>>>>> > >>>> >>>>>> > >>>> Thank you both and everyone else, >>>>>> > >>>> >>>>>> > >>>> Marcus >>>>>> > >>>> >>>>>> > >>>> On Wed, Apr 8, 2020, 10:21 AM Gus Heck <gus.h...@gmail.com> >>>>>> wrote: >>>>>> > >>>> While running it in an external node does ensure separability, >>>>>> I don't think it does a good job of addressing my other point of not >>>>>> needing to manage a 3rd server. It's still a server if it's started by >>>>>> java, and one still has to ensure it exists, and it will be extra hard to >>>>>> figure out how to configure it if started by Solr. >>>>>> > >>>> >>>>>> > >>>> I'm strongly in favor of us having a UI from my perspective as >>>>>> a consultant it makes discovery of things like their startup parameters >>>>>> and >>>>>> directories and such very easy (just go to front page of the admin >>>>>> screen), >>>>>> and it's so much easier to get a customer with security concerns and >>>>>> strict >>>>>> controls on who can access what (think banks, military, etc) to share a >>>>>> web >>>>>> session where they drive the UI than to get direct access to machines. >>>>>> It'll be a lot slower and much lower service to be making people wait >>>>>> while >>>>>> I craft curl statements to paste into the web session (and then fix the >>>>>> inevitable typos, or detect when they missed the last char of what I >>>>>> pasted, etc...). >>>>>> > >>>> >>>>>> > >>>> I definitely against Solr spawning some other server (node or >>>>>> otherwise) on it's own and thereby requiring additional system >>>>>> dependencies, or creating a second process that needs to be configured >>>>>> and >>>>>> properly secured. To me that's even worse than requiring the UI to run >>>>>> outside of Solr. We have a perfectly good web container already, and >>>>>> furthermore there's a much greater likelihood that maintainers will be >>>>>> facile with java/j2ee than anything else (IMHO). It's great if the >>>>>> framework we choose uses little or no JSP/Servlet and is modernized with >>>>>> a >>>>>> 100% javascript, templated etc. front end, but the back end should be >>>>>> java/jetty because we've got lots of java folks. >>>>>> > >>>> >>>>>> > >>>> If the back end matters deeply then you're not really >>>>>> programming to MVC/REST style... >>>>>> > >>>> >>>>>> > >>>> So there's another $0.02 :) and if you're not careful I'll >>>>>> give you an entire nickle's worth of ways people misuse/misunderstand the >>>>>> term REST :) >>>>>> > >>>> >>>>>> > >>>> -Gus >>>>>> > >>>> >>>>>> > >>>> On Tue, Apr 7, 2020 at 9:06 PM Marcus Eagan < >>>>>> marcusea...@gmail.com> wrote: >>>>>> > >>>> Gus, >>>>>> > >>>> >>>>>> > >>>> Your $.02 are worth a lot more than $.02 USD, so thank you. >>>>>> > >>>> >>>>>> > >>>> By separate app, I think I mean to endorse managed by a >>>>>> Node.js process started by NPM. I donât think that conflicts with what >>>>>> you >>>>>> have proposed. The NPM command should be issued by Java || or Bash but I >>>>>> donât think it would add significant overhead. Also, seems like on CI and >>>>>> or precommit hooks front end could be sizzled in parallel without adding >>>>>> much overhead. >>>>>> > >>>> >>>>>> > >>>> As for the front end framework, the most important things to >>>>>> consider in my view are simplicity and maintainability. We need to do a >>>>>> thorough analysis on the ecosystem and issues like the size of a React >>>>>> project vs Angular project vs Vue project, but React and Vue certainly >>>>>> have >>>>>> the velocity and the hearts if the front end community more than Angular. >>>>>> React is MIT license now and for the foreseeable >>>>>> > >>>> future thanks to the power and reach of its developers. >>>>>> > >>>> >>>>>> > >>>> <gus.h...@gmail.com> wrote: >>>>>> > >>>> +1 for Angular CLI / Typescript since I've fiddled with this >>>>>> in a minor way recently, Also MIT license is super friendly. >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> As a disenfranchised volunteer to the project, I also assume >>>>>> voters on specific choices like frameworks will be helping build in some >>>>>> respect at some point now or in the future. Is that a fair or misguided >>>>>> assumption? >>>>>> > >>>> >>>>>> > >>>> Marcus >>>>>> > >>>> >>>>>> > >>>> On Tue, Apr 7, 2020 at 17:15 Gus Heck <gus.h...@gmail.com> >>>>>> wrote: >>>>>> > >>>> +1 for Angular CLI / Typescript since I've fiddled with this >>>>>> in a minor way recently, Also MIT license is super friendly. >>>>>> > >>>> >>>>>> > >>>> Separate App - hmm... that's got some attraction, but also >>>>>> gives my stomach some churning when I think about solr now requiring >>>>>> management of 3 different servers (solr, something to serve UI and >>>>>> zookeeper). Adding more infrastructure gives me pause with respect to all >>>>>> the smaller installations. I've had several small self funded startup >>>>>> clients and a few clients with existing initial installs that they are >>>>>> outgrowing in places where procuring new machines and new software is a >>>>>> 6-12 mo endeavor and both types seem to squirm when I make suggestions >>>>>> such >>>>>> as running zookeeper separately, (let alone 3 of them). I think separate >>>>>> looks good for medium to large folks or very large companies that >>>>>> **already >>>>>> have** a solr expert on hand, but hurts the small clients and the >>>>>> departments in large orgs that got started with insufficient >>>>>> advice/expertise, so maybe >>>>>> > >>>> >>>>>> > >>>> - The UI should be installed by default >>>>>> > >>>> - it should be easy to remove it, or start with it disabled >>>>>> > >>>> - it should be self contained and separately downloadable. >>>>>> > >>>> >>>>>> > >>>> My recent fiddling included figuring out how to make angular >>>>>> CLI play nice in a J2ee war file structure seen here: >>>>>> https://github.com/nsoft/ns-login >>>>>> > >>>> >>>>>> > >>>> By play nice I mean, >>>>>> > >>>> - build creates a war file that "just works" when installed >>>>>> > >>>> - Angluar CLI commands work >>>>>> > >>>> - Angular serve command works (for auto-reloading ui changes, >>>>>> running on port 4200; note the use of proxy to allow it to talk to an >>>>>> already running web container) >>>>>> > >>>> >>>>>> > >>>> My $0.02, >>>>>> > >>>> >>>>>> > >>>> -Gus >>>>>> > >>>> >>>>>> > >>>> On Mon, Apr 6, 2020 at 11:03 AM JĂśrn Franke < >>>>>> jornfra...@gmail.com> wrote: >>>>>> > >>>> I think standalone would be very useful. >>>>>> > >>>> I propose Angular with Typescript - it fits to a more data >>>>>> centric approach with data types etc. >>>>>> > >>>> Maybe even two types of UIs - Admin UI and a simple Search UI. >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>>> Am 06.04.2020 um 16:53 schrieb Jan Høydahl < >>>>>> jan....@cominvent.com>: >>>>>> > >>>>> >>>>>> > >>>>> ďťżThanks for kickstarting this and bringing some fresh blood >>>>>> and enthusiasm :) >>>>>> > >>>>> >>>>>> > >>>>> Looks like others have had similar wish for a standalone Solr >>>>>> Admin App, hereâs a quick GitHub search for inspiration: >>>>>> > >>>>> >>>>>> > >>>>> https://github.com/savantly-net/solr-admin (Angular, nice >>>>>> screenshots, 1y old) >>>>>> > >>>>> https://github.com/kezhenxu94/yasa (vuejs, impressive >>>>>> screenshots, 2y old) >>>>>> > >>>>> https://github.com/thereactleague/galaxy (React, no >>>>>> screenshots, 4y old) >>>>>> > >>>>> >>>>>> > >>>>> They all seem abandoned but perhaps a new official effort >>>>>> could bring their developers in as contributors again? >>>>>> > >>>>> >>>>>> > >>>>>> the people who work on the Admin UI do not need to be >>>>>> expected to know the Java workflow, necessarily. This reality widens the >>>>>> net for who can contribute. >>>>>> > >>>>> >>>>>> > >>>>> Agree. Frontend devs have been a shortage in this project, >>>>>> and if we can make it easier to attract UI committers who feel at home >>>>>> and >>>>>> productive with the UI code, that would be a win. On the other hand, if >>>>>> we >>>>>> expect that the UI will be maintained by regular Java committers, then >>>>>> anything that makes it easier for them/us to contribute is also a win, >>>>>> like >>>>>> perhaps strongly-typed. >>>>>> > >>>>> >>>>>> > >>>>> Again, thanks Marcus for reviving this topic. Let us all try >>>>>> not to be overly ambitious here or shoot the initiative down with >>>>>> bikeshedding. It is far more important to fuel the energy and momentum >>>>>> and >>>>>> get something built than to remain stuck :) >>>>>> > >>>>> >>>>>> > >>>>> Jan >>>>>> > >>>>> >>>>>> > >>>>> >>>>>> > >>>>>> 6. apr. 2020 kl. 13:47 skrev Marcus Eagan < >>>>>> m...@marcuseagan.com>: >>>>>> > >>>>>> >>>>>> > >>>>>> Coming back to these existential questions from my phone: >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> Jan Høydahl >>>>>> > >>>>>> Added 1 hour ago >>>>>> > >>>>>> There are many opinions around admin UI. So I think the best >>>>>> place to start would be a new mail-thread in dev@ to discuss the way >>>>>> forward. Before we start a major re-work, we should probably ask >>>>>> ourselves >>>>>> a few existential questions: >>>>>> > >>>>>> ⢠Should we turn Amin UI into a standalone app instead of >>>>>> embedded in Solr? >>>>>> > >>>>>> >>>>>> > >>>>>> I think it should be a standalone app. There are many >>>>>> advantages gained from a separation of such concerns. Some of the ones >>>>>> include, the people who work on the Admin UI do not need to be expected >>>>>> to >>>>>> know the Java workflow, necessarily. This reality widens the net for who >>>>>> can contribute. >>>>>> > >>>>>> >>>>>> > >>>>>> Testing becomes a lot easier because JS developers are >>>>>> accustomed to building tests for static assets and self-contained node >>>>>> apps. They generally know less about testing a bit of JS within a massive >>>>>> Java project. The test could also run independently for changes that only >>>>>> affect the front end. Adding test coverage without adding time to tests >>>>>> sounds awesome. >>>>>> > >>>>>> >>>>>> > >>>>>> There are quite a few tickets over the years that have >>>>>> seemed to suggest that people want more fine-grained control over the >>>>>> Solr >>>>>> admin UI overall. Two recent tickets discussed topics like running a Solr >>>>>> Admin app on only one node and disabling it al together for whatever >>>>>> reason. See: https://issues.apache.org/jira/browse/SOLR-14014. >>>>>> > >>>>>> >>>>>> > >>>>>> ⢠What UI framework? Guess anything is better than current >>>>>> EOL, but will largely depend on who is willing to do the job! >>>>>> > >>>>>> Iâm happy to take this on (and willing to follow through on >>>>>> completing in my nights and weekends), but I am mostly framework >>>>>> agnostic. >>>>>> My stronge preference would be React, provided the license is kosher. >>>>>> There >>>>>> was one blip of âpractically unusable for most orgsâ a couple years back, >>>>>> but Facebook made it right really soon after. However, Iâm flexible. >>>>>> Angular (not JS) and Vue are also great. I would recommend we consider >>>>>> Typescript also because of the size of project and number of >>>>>> strongly-typed >>>>>> devs on this mailing list. My only reservation with TypeScript, though it >>>>>> may not apply in this case, is that the supersets of JS have changed a >>>>>> lot >>>>>> more than the frameworks. While CoffeeScript was an unnecessary layer of >>>>>> abstraction from my limited perspective, TypeScript might make JS more >>>>>> embraceable to a list of Java hackers. >>>>>> > >>>>>> >>>>>> > >>>>>> ⢠Current UI has no test coverage, can we do better with the >>>>>> new UI? >>>>>> > >>>>>> >>>>>> > >>>>>> Itâs imperative.React, Angular, and Vue each make it easy to >>>>>> include tests. >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> https://issues.apache.org/jira/browse/SOLR-12276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076204#comment-17076204 >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> -- >>>>>> > >>>> http://www.needhamsoftware.com (work) >>>>>> > >>>> http://www.the111shift.com (play) >>>>>> > >>>> -- >>>>>> > >>>> Marcus Eagan >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> -- >>>>>> > >>>> http://www.needhamsoftware.com (work) >>>>>> > >>>> http://www.the111shift.com (play) >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> -- >>>>>> > >>>> ----------------------------------------------------- >>>>>> > >>>> Noble Paul >>>>>> > >>>> >>>>>> > >>>> >>>>>> > >>>> -- >>>>>> > >>>> Marcus Eagan >>>>>> > >>>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> --------------------------------------------------------------------- >>>>>> > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>> > >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> >>>>>> > >>> -- >>>>>> > >>> http://www.needhamsoftware.com (work) >>>>>> > >>> http://www.the111shift.com (play) >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> --------------------------------------------------------------------- >>>>>> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>> > >> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> > >> >>>>>> > >>>>>> > >>>>>> --------------------------------------------------------------------- >>>>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> > >>>>>> >>>>>> >>>>>> -- >>>>>> ----------------------------------------------------- >>>>>> Noble Paul >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> >>>>>> -- >>>>> Marcus Eagan >>>>> >>>>> -- >>> Marcus Eagan >>> >>> > > -- > Marcus Eagan > >
