lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shad Storhaug (JIRA)" <>
Subject [jira] [Commented] (LUCENENET-565) Port Lucene.Net.Replicator
Date Wed, 28 Jun 2017 13:31:00 GMT


Shad Storhaug commented on LUCENENET-565:

{quote}However for now I wan't to stick as close to the original source as I think is possible
until all tests are ported and running.{quote}

I agree this is usually the best approach. However, every once in a while you find something
that has no direct equivalent in .NET and then it is time to be more creative. You basically
have 2 choices:

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

Since we are talking about very basic HTTP request/response stuff it would be easier to take
the latter approach IMO. True, you have to convert the tests (and possibly add more) as well,
but in the end you will end up with a true .NET-friendly design.

I wish there were some base-level generic interface in .NET that could be plugged into every
HTTP based framework, but unfortunately that doesn't seem to be the case. So it might just
be best to look at the documentation/functionality requirements and build it from the ground
up as one application (in this case MVC/WebAPI), then once it is working, refactor it to a
"general piece" that plugs into as many of the .NET APIs/frameworks as possible.

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.

> Port Lucene.Net.Replicator
> --------------------------
>                 Key: LUCENENET-565
>                 URL:
>             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

View raw message