Ok ... so I'm signing off ... guess I'll go the route of adding a sub-project in PLC4X to provide the things I need.
Chris On 08.07.21 11:46, Christofer Dutz wrote: > (Re sending as I noticed my first message went to only Davyd and not the > list) > > Hi Davyd, > > I was talking about a document in Confluence ... not a git repo. > And I guess I can help with all the getting started, once we've decided > on a plan. > > Chris > > On 07.07.21 09:52, Davyd McColl wrote: >> Hi Ralph >> >> I can't create a repo under the apache org on GitHub. I'm also perhaps not >> the best person to start off the project - I'm still very new to Go, having >> only worked a bit in it - learned enough to have had two PRs accepted to >> lazygit (https://github.com/jesseduffield/lazygit) and I'm not sure of the >> generally-accepted defaults / layout / structures for go projects. When I >> raised my paw, it was largely because I'd like to learn from people who do >> have this kind of experience (: I've found that working on lazygit has made >> me learn more than following a course, not in the least because there's >> existing code and structure there and people to tell me when I Do It Wrong :D >> >> I'm still very happy to be involved in log4go (assuming it's called that). >> >> -d >> On 2021/07/01 17:23:40, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> Davyd, >> >> You have commit rights but I am not sure if that gives you the ability to >> create a new repo. But before doing that I would create a confluence page to >> lay out the initial requirements and design. >> >> If you can’t create a repo and would like one I can certainly help with that. >> >> Ralph >> >>> On Jun 30, 2021, at 12:44 PM, Davyd McColl wrote: >>> >>> I'm rather new to go, but looking for ways to improve by writing code >>> alongside people who actually know what they're doing. If I can help, >>> please ping me. >>> >>> -d >>> >>> >>> On June 30, 2021 18:12:46 Christofer Dutz wrote: >>> >>>> Hi all, >>>> >>>> and sorry for being late to the party ;-) >>>> >>>> I am currently working hard on PLC4X' Go support and am also using what I >>>> create in the Open-Source project in some larger corporate applications. >>>> >>>> One thing that has always bugged me with go, was the inavailability of >>>> loggers that allow me to set different log levels for different parts of >>>> the application. In go with every half-efficient logging framework, it's >>>> an all or nothing thing. So if I want to track down a problem in my driver >>>> for protocol X and I switch logging to TRACE it's like trying to drink out >>>> of an open fire-hose. >>>> >>>> What I would love to do as a first step, and I don't think it should be >>>> too complicated, would be to create a Go API that allows us to define >>>> hierarchies of log levels, just like we know them in the Java world. This >>>> API would be used in the application to log, but it wouldn't actually do >>>> any logging but internally sort of use an underlying framework (possibly >>>> auto configured to TRACE or the most talkative log level) and forward log >>>> requests to that if it passes the filter criteria. >>>> >>>> So in PLC4Go for example we could use this Go Logging API. If my company >>>> now uses logrus or zerolog, then all we have to do in that application is >>>> initialize the log4go system (I know there's a project using that name >>>> pattern ... I'm referring to something we built) with the corresponding >>>> adapter. >>>> >>>> What do you think? I'm not one of these "I whish someone would build X for >>>> me" folks ... I am willing to put quite some effort into something like >>>> this. But I think it should be in a project like Apache Logging and not as >>>> a side project of PLC4X. >>>> >>>> Chris >>>> >>>> >>>> On 2020/12/11 12:20:18 Volkan Yazıcı wrote: >>>>> I support the initiative. At bol.com, we also needed to implement our own >>>>> Go logging layouts (JSON) and appenders (Redis). That said, I don't know >>>>> Go >>>>> and I don't think I will be able to spare time to both learn a new >>>>> language >>>>> (even though I am really into learning Go) and maintain such a project. I >>>>> mean, not that you need my help, but just wanted to share my availability. >>>>> If I would have time, I would rather clean up Log4j bugs piled up in JIRA. >>>>> I also agree with Matt that this would pave the road to standardizing the >>>>> logging configuration file formats across multiple languages. >>>>> What I witness most for code — in particular libraries, APIs, etc. — >>>>> written by programmers whose expertise is actually in another language, >>>>> that they mostly don't get the language conventions right. For instance, I >>>>> was horrified many times in the past to read/use Java code written by >>>>> JavaScript (front-end) developers. These two languages have totally >>>>> different approaches and (community embraced) conventions that one cannot >>>>> plug-n-play the mindset of one to another. In conclusion, as far as I >>>>> know, >>>>> none of us is programming in Go on a daily basis. Hence, I strongly >>>>> recommend consulting to experts in this domain before publishing something >>>>> to the outside world. For one, I am pretty sure there should be Go experts >>>>> within the Apache community, hence having expert reviews should be >>>>> relatively easy. Second, Apache has such a good track record in delivering >>>>> high quality software, even an inferior project might get quite some >>>>> attraction and we will be bound to maintain it for years. These are my >>>>> concerns in general. That said, I would be more than happy to ditch off >>>>> our >>>>> custom Go loggers with an Apache-approved alternative. >>>>> On Wed, Dec 9, 2020 at 10:29 PM Ralph Goers >>>>> wrote: >>>>>> The company I work for has started using Go for some of the middleware >>>>>> components we are developing. I have looked at several logging frameworks >>>>>> for Go and have not been impressed by any of them. As such, I am >>>>>> considering starting a project here. The major goals of this would be: >>>>>> >>>>>> Use an external configuration (at least JSON and XML). >>>>>> Allow the configuration to be accessed via HTTP(S) - Spring Cloud >>>>>> Configuration. >>>>>> Allow dynamic reconfiguration. >>>>>> Allow plugins (probably as Go plugins?) >>>>>> Support for Markers, context attributes, Layouts, Appenders. >>>>>> >>>>>> Anyone interested? >>>>>> >>>>>> Ralph >>>>>> >>>>>> >> >> >>
