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] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Wed, 28 Jun 2017 17:21:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16066895#comment-16066895
] 

Jens Melgaard commented on LUCENENET-565:
-----------------------------------------

{quote}1. Port over the parts you need from Apache Harmony (which is mostly equivalent to
the open JDK that Lucene uses, but with a free license we can use).
2. Boil the functionality down to its base mechanics and re-implement it using existing .NET
functionality.{quote}

I am taking the later approach, but without going to far, the thing is we can start by just
passing in HttpRequest and HttpResponse, they are not identical to the apache, but they are
close enough to be able to rationalize about the port, rather than going down the path of
setting up routing and building middle-ware and stuff...

With that a server can simply be configured to "app.Run(ctx => service.Perform(ctx.Request,
ctxResponse))"... That is to simple and not flexible enough for my taste in the end, but it
will server as a starting point from which I will find it easier to refactor from.

{quote}BTW - I noticed that you translated the writeUTF functionality to WriteString. Do note
that we have a DataInputStream and DataOutputStream in the Support.IO namespace that have
the binary compatible writeUTF and readUTF functionality along with writing the bytes out
in the big endian order that Java uses. In general, we have been trying to make any files
transferable between .NET and Java so we can read files that were written by a Java app in
Lucene. I haven't looked into whether this would be the case here or if it even makes sense
in this case. If it is advantageous to support interop with Lucene, it might be better to
change it; otherwise it would be best to use pure .NET APIs.{quote}

Arh... Wow that is confusing... So the reason for that i guess is that Lucene has https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.8.0/lucene/core/src/java/org/apache/lucene/store/DataInput.java
and https://github.com/apache/lucene-solr/blob/releases/lucene-solr/4.8.0/lucene/core/src/java/org/apache/lucene/store/DataOutput.java
classes... while Java has classes with equivalent names https://docs.oracle.com/javase/7/docs/api/java/io/DataInput.html
and https://docs.oracle.com/javase/7/docs/api/java/io/DataOutput.html... So when ReSharper
recognized the class name post-port, I just naturally assumed that it was correct and that
some decisions had just been made to cut something from the port... >.<...
But will fix that ofc.

> 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