I'm playing with the high-level ES Java APIs now to see how easy it
will be to create a new Receiver that allows Chainsaw to query Elastic
Search directly.

It looks like it'll be pretty simple.

Scott

On 11/12/17, Matt Sicker <boa...@gmail.com> wrote:
> 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>
>

Reply via email to