Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id C79B0200BA3 for ; Thu, 20 Oct 2016 08:42:43 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id C623B160AE0; Thu, 20 Oct 2016 06:42:43 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 95DDE160ADB for ; Thu, 20 Oct 2016 08:42:42 +0200 (CEST) Received: (qmail 58732 invoked by uid 500); 20 Oct 2016 06:42:41 -0000 Mailing-List: contact log4net-dev-help@logging.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Log4NET Dev" List-Id: Delivered-To: mailing list log4net-dev@logging.apache.org Received: (qmail 58715 invoked by uid 99); 20 Oct 2016 06:42:41 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Oct 2016 06:42:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 90ABD180647 for ; Thu, 20 Oct 2016 06:42:40 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.79 X-Spam-Level: * X-Spam-Status: No, score=1.79 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id PIrK5tbv9uAS for ; Thu, 20 Oct 2016 06:42:36 +0000 (UTC) Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 575125FBF0 for ; Thu, 20 Oct 2016 06:42:36 +0000 (UTC) Received: by mail-qk0-f170.google.com with SMTP id f128so71736900qkb.1 for ; Wed, 19 Oct 2016 23:42:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=BOa+2+l9lmOtJkqd6fStxCzzIbwdPBusD0X15JgwmyM=; b=hDFuVopvTv4+cBnPNzISAC8P3EEdD4d97i0li4NwJ5uBqItG8VLlUWOBPV5wCehjpX LQhAhSrJAWIbm7cQ7xgymH4i+rbZ5wjQFGX2FUTzBG9Gf9dlQPiHgQFcYUzPoUJRJXva dad+ovogtQ4s5oUX6F/vr6dVVDlcE8JvTnhcw+2ur0zYuraPpESJKhFeOso5RGmfoJCn vwBcMRI2ksGw9lcvDpISO6iAvjS8Q76n+cIxauDOqkoci7WSYpraNr4qXccYFqQqlQ3r Ysxo8fajOrp4IT3eWOgMEvqrSr0dXLXfShB0vs05v3ReYMt2iGitReO7etYHpFlAm1hF VT0w== X-Gm-Message-State: AA6/9Rm6FonsmnxlRmiJkk2/b0eND8SEDow8eQYeJK5mpoIcB73noAlMH7FzfTPU5OGpiQ== X-Received: by 10.194.83.130 with SMTP id q2mr7300798wjy.133.1476945755619; Wed, 19 Oct 2016 23:42:35 -0700 (PDT) Received: from [192.168.0.192] (etrn.topcontrol.it. [217.199.15.225]) by smtp.gmail.com with ESMTPSA id g17sm76048495wjs.38.2016.10.19.23.42.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 23:42:34 -0700 (PDT) Subject: Re: Response to call to arms To: log4net-dev@logging.apache.org References: <24368ce6-5a94-ba9f-8ed8-e4ef275c7915@apache.org> From: Dominik Psenner Message-ID: <40ac59bc-94c2-d4c3-7b1b-68acbe54240d@apache.org> Date: Thu, 20 Oct 2016 08:42:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8045170F0FE9F6D252DB3233" archived-at: Thu, 20 Oct 2016 06:42:44 -0000 This is a multi-part message in MIME format. --------------8045170F0FE9F6D252DB3233 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit You've got the point. Obviously this all greatly depends what needs to get done. Let me outline this with an example: Requirement: we want log4net to have an API where users must not invoke IsLogLevelEnabled to check if a log level is enabled and we want to have this without changing the current public API of the ILog interface Implementation: we are going to implement this with lambdas Implementation dependencies: this in turn requires us to target at least net 3.5 and above The outcome of this example is the log4net.Utils.ILogExtensions static class. Cheers, Dominik On 2016-10-19 20:02, Joe wrote: > > Thanks for the response. > > I dont think theres any rush to remove the ifdefs for obsolete > platforms ; the important thing is to know we dont need to add them > for new code. > > As a minor example I recently contributed code which measured elapsed > time using DateTime.UtcNow: Id probably have used a Stopwatch had I > known .NET 1.x support was not required. > > By implication you are planning to continue to target .NET 2.0 so > presumably the rules are: > > -Avoid using features from .NET 3.5+ in core components > > -Its OK to depend on .NET 3.5 for new loosely-coupled components such > as Appenders in this case the whole file just needs to be included > in an #ifdef > > Ill start off by looking at LOGNET-407 as suggested by Stefan. > > *From:*Dominik Psenner [mailto:dpsenner@apache.org] > *Sent:* 19 October 2016 10:29 > *To:* log4net-dev@logging.apache.org > *Subject:* Re: Response to call to arms > > Hi Joe, > > good to read you and welcome on the dev list! You're free to work on > issues that attract your attention. Nobody's going to force you to > work on things you don't deem to be worth the effort. > > We've already decided to gradually drop official support for ancient > .net frameworks like .NET 1.X. We are no longer going to actively > maintain those targets and if changes to the codebase break those > targets we are no longer going to fix that unless someone else > provides a patch that restores compatibility. This means that we are > shifting the responsibility of maintenance to whoever requires the > latest log4net version to work on those ancient platforms. > > Further, compact framework mostly does not support several appenders > that for example target the System.Net namespace. Please correct me if > I'm wrong, but from memory a prominent example appender is the > EmailAppender. I agree with you that it would be a great improvement > if we were able to refactor away all those #ifdef's. Unfortunately > this wish is very hard to achieve, even impossible if we wanted to > stay backwards compatible. > > Backwards compatibility is the next thing I would like to mention. > log4net is a logging framework and one of the highest goods is its > backwards compatibility. If we are going to break that we must follow > a path similar to that of log4j2. In that world the old API facades > the log4j2 API and therefore migration of existing code is trivial. > > Cheers and greets,Dominik > > On 2016-10-18 22:42, Joe wrote: > > I'm responding to Stefan's call-to-arms, though I have limited > time available, currently probably not more than a day or two a month. > > Given my lack of time I would probably want to get involved in > specific short-term tasks, such as taking on issues from the issue > tracker, rather than being a driver to shape the future of log4net. > > I have been involved recently in writing a custom asynchronous > appender that logs to a WebAPI, so asynchronous appenders is one > area I could get involved in. > > One thing I'd personally like to see is to drop support for some > legacy platforms: > > - The few .NET 1.x users left are probably adequately served by > existing versions of log4net. > > - It's not onerous for .NET 2.0/3.0 users to upgrade to .NET > 3.5, so these could maybe be dropped too (existing apps dont need > to be rebuilt; they just need to ensure 3.5 is installed). > > - I've no experience with Compact Framework, but wonder > whether, given the platform restrictions, it would be better > served going forward by a separate code base with a simplified and > restricted logging framework that exposes an identical API to > applications. > > Doing this would make development easier, for example by allowing > the use of generics and Linq. > > Which in turn might attract more developers ... > > One way to approach it would be to remove the binaries for these > platforms from the next release, and only remove from the source > code if a reasonable period elapses without too much wailing and > gnashing of teeth. > --------------8045170F0FE9F6D252DB3233 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

You've got the point. Obviously this all greatly depends what needs to get done. Let me outline this with an example:

Requirement: we want log4net to have an API where users must not invoke IsLogLevelEnabled to check if a log level is enabled and we want to have this without changing the current public API of the ILog interface
Implementation: we are going to implement this with lambdas
Implementation dependencies: this in turn requires us to target at least net 3.5 and above

The outcome of this example is the log4net.Utils.ILogExtensions static class.

Cheers,
Dominik

On 2016-10-19 20:02, Joe wrote:

Thanks for the response.

I dont think theres any rush to remove the ifdefs for obsolete platforms; the important thing is to know we dont need to add them for new code.

As a minor example I recently contributed code which measured elapsed time using DateTime.UtcNow: Id probably have used a Stopwatch had I known .NET 1.x support was not required.

By implication you are planning to continue to target .NET 2.0 so presumably the rules are:

- Avoid using features from .NET 3.5+ in core components

- Its OK to depend on .NET 3.5 for new loosely-coupled components such as Appenders in this case the whole file just needs to be included in an #ifdef

Ill start off by looking at LOGNET-407 as suggested by Stefan.

From: Dominik Psenner [mailto:dpsenner@apache.org]
Sent: 19 October 2016 10:29
To: log4net-dev@logging.apache.org
Subject: Re: Response to call to arms

Hi Joe,

good to read you and welcome on the dev list! You're free to work on issues that attract your attention. Nobody's going to force you to work on things you don't deem to be worth the effort.

We've already decided to gradually drop official support for ancient .net frameworks like .NET 1.X. We are no longer going to actively maintain those targets and if changes to the codebase break those targets we are no longer going to fix that unless someone else provides a patch that restores compatibility. This means that we are shifting the responsibility of maintenance to whoever requires the latest log4net version to work on those ancient platforms.

Further, compact framework mostly does not support several appenders that for example target the System.Net namespace. Please correct me if I'm wrong, but from memory a prominent example appender is the EmailAppender. I agree with you that it would be a great improvement if we were able to refactor away all those #ifdef's. Unfortunately this wish is very hard to achieve, even impossible if we wanted to stay backwards compatible.

Backwards compatibility is the next thing I would like to mention. log4net is a logging framework and one of the highest goods is its backwards compatibility. If we are going to break that we must follow a path similar to that of log4j2. In that world the old API facades the log4j2 API and therefore migration of existing code is trivial.

Cheers and greets,Dominik

On 2016-10-18 22:42, Joe wrote:

I'm responding to Stefan's call-to-arms, though I have limited time available, currently probably not more than a day or two a month.

Given my lack of time I would probably want to get involved in specific short-term tasks, such as taking on issues from the issue tracker, rather than being a driver to shape the future of log4net.

I have been involved recently in writing a custom asynchronous appender that logs to a WebAPI, so asynchronous appenders is one area I could get involved in.

One thing I'd personally like to see is to drop support for some legacy platforms:

- The few .NET 1.x users left are probably adequately served by existing versions of log4net.

- It's not onerous for .NET 2.0/3.0 users to upgrade to .NET 3.5, so these could maybe be dropped too (existing apps dont need to be rebuilt; they just need to ensure 3.5 is installed).

- I've no experience with Compact Framework, but wonder whether, given the platform restrictions, it would be better served going forward by a separate code base with a simplified and restricted logging framework that exposes an identical API to applications.

Doing this would make development easier, for example by allowing the use of generics and Linq.

Which in turn might attract more developers ...

One way to approach it would be to remove the binaries for these platforms from the next release, and only remove from the source code if a reasonable period elapses without too much wailing and gnashing of teeth.


--------------8045170F0FE9F6D252DB3233--