From dev-return-10435-apmail-lucenenet-dev-archive=lucenenet.apache.org@lucenenet.apache.org Fri Jul 28 15:28:56 2017 Return-Path: X-Original-To: apmail-lucenenet-dev-archive@www.apache.org Delivered-To: apmail-lucenenet-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 46EBF19702 for ; Fri, 28 Jul 2017 15:28:56 +0000 (UTC) Received: (qmail 67426 invoked by uid 500); 28 Jul 2017 15:28:56 -0000 Delivered-To: apmail-lucenenet-dev-archive@lucenenet.apache.org Received: (qmail 67387 invoked by uid 500); 28 Jul 2017 15:28:56 -0000 Mailing-List: contact dev-help@lucenenet.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucenenet.apache.org Delivered-To: mailing list dev@lucenenet.apache.org Received: (qmail 67375 invoked by uid 99); 28 Jul 2017 15:28:55 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jul 2017 15:28:55 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id AF7DCE024D; Fri, 28 Jul 2017 15:28:55 +0000 (UTC) From: AndyPook To: dev@lucenenet.apache.org Reply-To: dev@lucenenet.apache.org References: In-Reply-To: Subject: [GitHub] lucenenet issue #209: RFC: LUCENENET-565: Porting of Lucene.Net.Replicator Content-Type: text/plain Message-Id: <20170728152855.AF7DCE024D@git1-us-west.apache.org> Date: Fri, 28 Jul 2017 15:28:55 +0000 (UTC) Github user AndyPook commented on the issue: https://github.com/apache/lucenenet/pull/209 Just sticking my 2p/2c in again... Having this as middleware with a ```UseLuceneReplicator("rootPrefix", service)``` would be a lot more "natural" from an aspnetcore point of view. Part of the reason that the controller looks a little odd is due to the signature of ```Perform```. It is odd to use the Request/Response properties in a Controller. In order to make the routing work it also needs "{path*}" and the arg etc which is ignored cos it actually pulls those direct from the Request. Looking at how Perform works, middleware taking control of the req/res at the owin layer without all the mvc/routing shenanigans. Having it intercept a few path(s) (ie ```StartsWith(routprefix```) would seem the "right thing to do". That way the developer can just add the middleware without needing to get involved in creating a "weird" controller or messing with routing or thinking about DI or... The MVC feature is just middleware after all. I think there may be an odd side effect if an exception occurs part way through. ie a partial response with a json serialized exception added to the end which would be hard for the client to deal with (although if this is how the java version works...). Or if you think the Controller approach is better, I could imagine wrapping some of the behavior in a custom ```IActionResult```. This could deal with handling the exception and creating the right kind of http response. This would leave the ReplicationService with just creating the stream. Might also be worth digging into how aspnetcore deals with big streams (ie does it buffer them in memory before sending the first byte like old asp/iis did or can it do something smarter). Anyway, just some thoughts... what do you think? I ought to put my money where my mouth is, write some code and contribute :) I haven't used VS2015 in what seems like forever. We'll see what the weekend brings --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastructure@apache.org or file a JIRA ticket with INFRA. ---