Hi all,

so I don't have the karma to create a page (probably also not for 
editing it) I would really like to start with this. So could someone 
with the ability to do so, grant me the karma to create and edit pages 
(created by myself) in your wiki?

Chris


On 01.07.21 18:28, Christofer Dutz wrote:
> Hi all,
> 
> as far as I know, PMCs have the carma to create repos.
> 
> And sure ... happy to do a rough plan before starting to write code. As
> long as it's not like writing a RFC document. If you or someone here
> could setup a root document, we could start writing and drawing.
> 
> Chris
> 
> 
> On 01.07.21 17:23, Ralph Goers 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 <dav...@gmail.com> 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 <cd...@apache.org> 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 <ralph.go...@dslextreme.com>
>>>>> 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
>>>>>>
>>>>>>
>>
>>

Reply via email to