lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Pook <andy.p...@gmail.com>
Subject Re: [jira] [Comment Edited] (LUCENENET-565) Port Lucene.Net.Replicator
Date Fri, 23 Jun 2017 14:29:51 GMT
Not sure I have the right end of the stick here, but...

AspNetCore absolutely "supports" owin, Owin is at it's center (I was about
to say "core"). There are several abstractions layered on top, so it may
not be totally obvious.

The "Core" part of the name is definitely confusing. There is some
historical relationship between AspNet-Core and DotNet-Core but it's best
to think of them as separate things. May as well call it AspNetFred or
AspNetVNext or AspNetRethoughtFromTheGroundUp.
It's such a big change that just a major version number bump wasn't seen as
enough. It's more that a breaking change. It a complete rewrite.

AspNetCore will run on top of both DotNetCore and DotNet-Framework (ie the
"old" dot net. 4.5.1 onwards, I think).

netStandard is yet another thing. It is a standard defining the api's
available for a given implementation of dotnet. Lower versions of Standard
define smaller sets of api's. So, if you restrict your code to only using
netStandard-1.3 then it will run on smaller implementations of dotnet
(think IoT) or be more likely to be cross platform (think early versions of
Xamarin or DotNetCore).
netStandard-2.0 is where it gets interesting as it becomes possible to
easily reference "legacy" assemblies from new DotNetCore code.
The idea is to be able to write against netStandard and have the same
assembly runable on any platform that supports that version of the Standard
(Win, Mac, Linux at the mo and I believe there are ARM implementations too,
so RaspberryPi etc).


If you're looking for an http listener you should probably look into
Kestrel. This is the new http "server" layer. Cross platform, self hostable
etc. They've been getting some really nice perf out of it.

Hope I'm helping rather than frustrating even more.

On 23 June 2017 at 10:07, Jens Melgaard (JIRA) <jira@apache.org> wrote:

>
>     [ https://issues.apache.org/jira/browse/LUCENENET-565?
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&
> focusedCommentId=16060602#comment-16060602 ]
>
> Jens Melgaard edited comment on LUCENENET-565 at 6/23/17 9:06 AM:
> ------------------------------------------------------------------
>
> OK, did some digging.
> Right now I am perhaps more confused than ever. (Granted I have been
> confused about Owin, AspNetCore etc. for a while now, not really seeing
> where MS is headed with it)...
>
> As far as I can tell Owin won't actually be use-able as it seems you can't
> get that into .Net Core. (Maybe that changes as of .Net Standard 2.0, where
> things can be pulled in though a compatibility shim, but then we need to be
> sure Owin does not use anything that is not supported, while doubtful it
> wouldn't be fully supported, that is perhaps not an ideal solution)...
>
> AspNetCore 1.1.2 seems to target .Net Standard 1.3 so that certainly runs
> on both, (making the name ever so confusing)...
>
> AspNetCore does not implement Owin though (Owin does not support Core, so
> duh i guess... it does align to the same ideas somewhat)...
> There is however bridge solution that allows you to host Owin middleware
> and applications on top of AspNetCore and the other way around, they are
> not straight forward though, but at the same time they don't seem to
> complicated either, obviously they can only be used under .Net Framework
> but that wouldn't matter as it would be the consumers choice.
>
> {color:red}*//RANT ON*{color}
> _{color:gray}With all these new things, .Net Core, .Net Framework, .Net
> Standard, AspNetCore  - This is giving me a real headache >.<... But .Net
> Standard gives me hope for the future, but it seems to be a bumpy and
> somewhat painful ride before we get there. Again... Maybe much of that pain
> is over as 2.0 arrives, but it's not there yet :S (That will also remove
> the project.json files again but the .csproj files will be greatly
> simplified... back and forth i guess >.<.)...{color}_
> {color:red}*//RANT OFF*{color}
>
> I Think the conclusion is that we either stick with System.Net (I have not
> checked if that is possible in terms of a listener) and System.Net.Http
> (Will be used with the client regardless of our choice) OR we go with
> AspNetCore... I am probably leaning towards the later...
>
> Curiosity question: Will there be any plans to move up to  2.0[
> https://github.com/dotnet/standard/blob/master/docs/
> versions/netstandard2.0.md](.Net Standard) ones that is done?...
> (Considering the amount of API's they have added)
>
> As for all the "minor" comments... I will focus on the above first, as
> getting that in place (or not) is kind of a deal breaker.
> Just so you don't think I am ignoring them as changes happen on the http
> stuff ^^.
>
>
> was (Author: jmd):
> OK, did some digging.
> Right now I am perhaps more confused than ever. (Granted I have been
> confused about Owin, AspNetCore etc. for a while now, not really seeing
> where MS is headed with it)...
>
> As far as I can tell Owin won't actually be use-able as it seems you can't
> get that into .Net Core. (Maybe that changes as of .Net Standard 2.0, where
> things can be pulled in though a compatibility shim, but then we need to be
> sure Owin does not use anything that is not supported, while doubtful it
> wouldn't be fully supported, that is perhaps not an ideal solution)...
>
> AspNetCore 1.1.2 seems to target .Net Standard 1.3 so that certainly runs
> on both, (making the name ever so confusing)...
>
> AspNetCore does not implement Owin though (Owin does not support Core, so
> duh i guess... it does align to the same ideas somewhat)...
> There is however bridge solution that allows you to host Owin middleware
> and applications on top of AspNetCore and the other way around, they are
> not straight forward though, but at the same time they don't seem to
> complicated either, obviously they can only be used under .Net Framework
> but that wouldn't matter as it would be the consumers choice.
>
> {color:red}*//RANT ON*{color}
> With all these new things, .Net Core, .Net Framework, .Net Standard,
> AspNetCore  - This is giving me a real headache >.<... But .Net Standard
> gives me hope for the future, but it seems to be a bumpy and somewhat
> painful ride before we get there. Again... Maybe much of that pain is over
> as 2.0 arrives, but it's not there yet :S (That will also remove the
> project.json files again but the .csproj files will be greatly
> simplified... back and forth i guess >.<.)...
> {color:red}*//RANT OFF*{color}
>
> I Think the conclusion is that we either stick with System.Net (I have not
> checked if that is possible in terms of a listener) and System.Net.Http
> (Will be used with the client regardless of our choice) OR we go with
> AspNetCore... I am probably leaning towards the later...
>
> Curiosity question: Will there be any plans to move up to  2.0[
> https://github.com/dotnet/standard/blob/master/docs/
> versions/netstandard2.0.md](.Net Standard) ones that is done?...
> (Considering the amount of API's they have added)
>
> As for all the "minor" comments... I will focus on the above first, as
> getting that in place (or not) is kind of a deal breaker.
> Just so you don't think I am ignoring them as changes happen on the http
> stuff ^^.
>
> > Port Lucene.Net.Replicator
> > --------------------------
> >
> >                 Key: LUCENENET-565
> >                 URL: https://issues.apache.org/jira/browse/LUCENENET-565
> >             Project: Lucene.Net
> >          Issue Type: Task
> >          Components: Lucene.Net.Replicator
> >    Affects Versions: Lucene.Net 4.8.0
> >            Reporter: Shad Storhaug
> >            Priority: Minor
> >              Labels: features
> >
>
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.4.14#64029)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message