lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Melgaard (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENENET-565) Port Lucene.Net.Replicator
Date Fri, 23 Jun 2017 09:07:00 GMT

    [ 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
View raw message