I'm heavily opposed to myself being involved in any non-trivial web UI code until some semblance of sanity arises in that space (see for example the Elm programming language which does a good job toward accomplishing some of that). Electron, while a cool piece of technology, is not my ideal way to implement a GUI. Since we're all familiar with the JVM and its tech, Swing or JavaFX are some of the best bets there. If we were looking outside that space, I'd recommend using the Qt framework which would be more of a C++ thing at that point (though I know it supports all sorts of scripting things nowadays).
Allowing Chainsaw to integrate with remote logging/monitoring services for obtaining log data and whatnot, however, would be a neat addition. I haven't had a chance to dive into the code yet, but I'd imagine that there may be some sort of boundary in place (or can be put in place) between the UI and the logic such that multiple UIs can reuse the same code. That sort of pattern is not specific to web development. :) On 12 November 2017 at 08:50, Mikael Ståldal <mi...@apache.org> wrote: > Having said that, I don't mean that Ole Ersoy's idea is inherently bad. > But it should be a new independent project (possibly in Apache Logging > Services). > > > > On 2017-11-12 14:27, Mikael Ståldal wrote: > >> To me, that sound like transforming it into something completely >> different, and a use case which there already exists quite some other tools >> for already. >> >> Shouldn't we keep Chainsaw as a stand-alone desktop UI app? >> >> >> On 2017-11-12 05:22, Ole Ersoy wrote: >> >>> I had a brief peek. My first impression was that the whole thing needs >>> a facelift. I'm currently I'm reviewing the ELK stack with the Kibana user >>> interface as well as fluentd and Zipkin. Something that unifies these >>> things would be very attractive. If the UI is modern then even more so. >>> If we can deploy it as a progressive web app attachable to a GraphQL >>> provider that gets feeds from Fluentd and the ELK stack that would >>> definitely get Chainsaw back in the game. I think you would have an easy >>> time attracting a talent pool for something like that. For example >>> http://akveo.github.io/blur-admin/ is currently available on Github and >>> has 8000 stars. Could be the starting point for the next generation >>> logging UI. >>> >>> Cheers, >>> >>> Ole >>> >>> >>> On 11/11/2017 06:09 PM, Scott Deboy wrote: >>> >>>> I'd love to hear what folks think of the user experience with the >>>> 'latest Chainsaw' and its feature set. >>>> >>>> There are a ton of features. It will be interesting to get a sense of >>>> how many of those features we get 'for free' in any of these other UI >>>> toolkits. It was a lot of heavy lifting to get Swing to do what we >>>> wanted. >>>> >>>> Scott >>>> >>>> >>>> On 11/11/17, Ole Ersoy <ole.er...@gmail.com> wrote: >>>> >>>>> Kotlin is almost a duplicate of Typescript, so Javascript devs should >>>>> be >>>>> able to pickup on it fast. There's a Typescript to Kotlin converter >>>>> here: >>>>> >>>>> https://github.com/Kotlin/ts2kt >>>>> >>>>> Typescript is also supported in Electron: >>>>> >>>>> https://electron.atom.io/blog/2017/06/01/typescript >>>>> >>>>> So Kotlin should be a pretty good bridge between these worlds and >>>>> opens up a >>>>> lot of possibilities ... Suggested Kotlin to the Hipparchus group as >>>>> well: >>>>> >>>>> https://github.com/Hipparchus-Math/hipparchus/issues/26 >>>>> >>>>> A chainsaw implementation in Electron would provide a better developer >>>>> and >>>>> user experience I would think though ... as you can now use the latest >>>>> Javascript frameworks (Angular / React) and all the packages that come >>>>> with >>>>> that ecosystem (Graphing, Widgets, etc.) >>>>> >>>>> https://scotch.io/tutorials/creating-desktop-applications-wi >>>>> th-angularjs-and-github-electron >>>>> >>>>> >>>>> On 11/11/2017 04:42 PM, Matt Sicker wrote: >>>>> >>>>>> I've been using Java for years, Scala for several months (all of OOP, >>>>>> hybrid, and pure FP styles in different projects), and other >>>>>> languages in >>>>>> the past. I've certainly found Scala to be useful in the Big Data >>>>>> space, >>>>>> especially when using Spark, though I've also found it useful in >>>>>> projects >>>>>> that consume Java APIs. >>>>>> >>>>>> As for Kotlin fitting well to a GUI app, based on its traction in the >>>>>> Android GUI space, I had the same thought. Plus, this may attract more >>>>>> contributors outside ASF who are interested in using Kotlin or >>>>>> working on >>>>>> a >>>>>> GUI app instead of low level Java bits. >>>>>> >>>>>> Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to >>>>>> pick >>>>>> up on than Scala, so that also helps with adoption in theory. >>>>>> >>>>>> On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org> >>>>>> wrote: >>>>>> >>>>>> I have used both Java and Scala for several years, and I have been >>>>>>> trying >>>>>>> out Kotlin the latest months (for Android only). >>>>>>> >>>>>>> I would say it is definitely easier for a developer with primarily >>>>>>> Java >>>>>>> experience to pick up Kotlin than Scala, especially if that Java >>>>>>> experience >>>>>>> is predominately pre-Java8. If your primary experience is functional >>>>>>> programming like Haskell, O'Caml or F#; then Scala is probably >>>>>>> easier to >>>>>>> pick up. >>>>>>> >>>>>>> Kotlin is gaining traction in Android, since it works well there. >>>>>>> Scala >>>>>>> is >>>>>>> big in Big Data (Apache Spark etc) and to some extent in >>>>>>> server/backend. >>>>>>> >>>>>>> Kotlin might be a better fit for a desktop UI Java app like Chainsaw. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2017-11-11 02:10, Gary Gregory wrote: >>>>>>> >>>>>>> I think Kotlin would be more approachable than Scala... thoughts? >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker <boa...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 10 November 2017 at 16:17, Robert Middleton <osfan6...@gmail.com >>>>>>>> > >>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> What would the advantage be of using Scala vs just normal Java? >>>>>>>>> >>>>>>>>>> Mostly from a curiosity standpoint; I've never done Scala so I >>>>>>>>>> don't >>>>>>>>>> know it works. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The main advantage I can see is that most of the developers >>>>>>>>> interested >>>>>>>>> in >>>>>>>>> working on v3 all prefer to work in Scala. I could go on and on >>>>>>>>> about >>>>>>>>> Scala >>>>>>>>> over Java, but really, my comparison would all come down to >>>>>>>>> functional >>>>>>>>> programming over object oriented programming. When it comes to >>>>>>>>> shared >>>>>>>>> libraries like Log4j, I find Java far more appropriate and work in >>>>>>>>> that >>>>>>>>> space. In a GUI application where there is no real public API? I'd >>>>>>>>> rather >>>>>>>>> work in Scala. Kotlin was another option, but it seems like none >>>>>>>>> of us >>>>>>>>> really have experience there. >>>>>>>>> >>>>>>>>> >>>>>>>>> Did you actually have trouble building? I'm pretty sure that when >>>>>>>>> I >>>>>>>>> >>>>>>>>>> built it a few months ago I simply opened up the project in >>>>>>>>>> Netbeans >>>>>>>>>> and it built immediately as a maven project(although looking at >>>>>>>>>> the >>>>>>>>>> POM it does look like it uses ant on the backend for some reason). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Building the project is simple enough. I had issues with: >>>>>>>>> >>>>>>>>> 1. Running mvn clean install does not work by default unless you >>>>>>>>> run >>>>>>>>> "mvn >>>>>>>>> site:site" before running "mvn install". >>>>>>>>> 2. Doesn't build in Java 9. >>>>>>>>> 3. The maven-release-plugin is not configured at all, so I had to >>>>>>>>> do >>>>>>>>> all >>>>>>>>> release steps by hand instead. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> . >>>> >>>> >>> >> > -- Matt Sicker <boa...@gmail.com>
