It's definitely always been a relatively simple 'log event-focused'/tabular data tool. Basically:
- Pull in data from sources (usually files-local or ssh-able) - parse the data into fields - route the data to one or more tabs - render the events into a table - support filter, search, colorize and sort-all using a common expression syntax, sort of a simpler version of logstash's grok. Dashboard/visualization support would be awesome, but this is both a real time as well as offline analysis tool. Cursor-style previous/next page event rendering would make it a terrible user experience IMO. Scott On Nov 11, 2017 8:22 PM, "Ole Ersoy" <ole.er...@gmail.com> 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> >>>>>>> >>>>>>> >>>>>>> >>> . >> >> >
