Github user jeme commented on the issue:

    https://github.com/apache/lucenenet/pull/209
  
    Ok so I think I will give up on commenting on all of the above because 
there is to much. I will as a general note say be careful that you don't get 
ahead of your self.
    
    I personally think it would be a bad idea to put to much of all that 
AspNetCore, Owin etc. into this particular project (project as Lucene in a 
whole, not each csproj file)...
    
    Instead I would separate them out and give them meaningful project names... 
and give them their own release cycle...  (Actually I think the 
Lucene.Net.Replicator.AspNetCore project would belong in one of those "child 
projects", but that is a bit complicated as it's currently needed for tests, it 
might be possible to write the tests differently without it or add a 
minimalistic implementation into test instead)
    
    They could still be under "Lucene.Net" organisation wise, but I think there 
would be many advantages in allowing them to have their own repo and life...
    
    This would focus this repository on the port of lucene (as direct as 
possible, but also to support these projects) and each project could have it's 
individual focus... (Lucene on AspNetCore for all AspNetCore integration on 
different levels, Lucene on Nancy for that etc.)...
    
    Also, your already on the edge of making some decisions that would be bad 
for larger scale projects... E.g. making a Singleton LuceneWriter (registered 
in a IoC Container or not) wouldn't that limit you to only having a single 
index?... that would seem like an odd direction to consider within this context 
as the Replicator directly supports shards... (aka multiple indexes?)
    
    It also seems that as things are right now you can't release each 
individual csproject on it's own from here?... (E.g. releasing just the 
Lucene.Net package and not the rest?)... If that is the case then I think that 
speaks even more for putting these more "platform" specific integrations into 
their own project/repo/release cycle so they are not bound by each other... So 
that these packages could be release on a much more rapid cycle than Lucene.Net 
it self. 
    
    There is ofc. many considerations around such "branching out", but from 
having done so quite a few time my self on our own projects, I can say that it 
is so much more convenient in the long run...
    
    As a final note, I won't be able to find time to take the 
Lucene.Net.Replicator.AspNetCore project much further, my goal was to focus on 
Lucene.Net.Replicator it self and provide a meaningful port of that that could 
be integrated into AspNetCore (which we haven't even adopted yet), AspNet4x, 
Nancy or similar frameworks with relative ease...
    
    Which path you take with Lucene.Net.Replicator.AspNetCore is up to you... 
But I don't feel right about building anything two involved for a 
framework/platform I don't even use and therefore don't know all the ins and 
outs of...
    
    To me it was an example integration that could help me find points in the 
Lucene.Net.Replicator which might cause difficulty when integrating or straight 
out felt wrong and there are a few things about the ReplicatorService that 
annoys me in that regard, but there is a broader picture as the HttpReplicator 
aligns to that same theme and then there is your desire to stay compatible with 
Java versions, which is questionably because they choose to actually serialize 
Exception objects, if java clients expect any meaning of that then we are not 
compatible at all as all Exceptions would end up as "Unknown Exceptions" in a 
Java client... and that goes for the other way around as well...
    
    I do have a small super simplistic and extremely crude DEMO AspNetCore app 
that indexes and publishes data and then a Console client that pulls the 
replicas which works. I am trying to use this to weed out annoyances. 


---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to