taoensso/nippy

Support for Clojure CLR?

luposlip opened this issue · 6 comments

luposlip commented

Hi @ptaoussanis !

I'm using nippy for my nd-db library, and I like it a lot 👍🏽

I'm part of a team where around 75% of the people uses dotnet (C# and the likes).
I'd really like to port my library to Clojure CLR, but can't make that port per se, since nippy is JVM only.

Do you know how difficult it would be to make nippy work with Clojure CLR?
I wouldn't mind making a PR, but haven't spend any time yet looking into it.

Thanks.

ptaoussanis commented

@luposlip Hi Henrik,

In principle I don't expect that would be too difficult. I'm guessing that .net should have equivalent/similar types and interfaces. May be non-trivial though.

A couple factors that I'd expect would influence difficulty:

  1. Would this be a fork, or addition to Nippy core? I'd expect the latter might be tougher, since it'd need to be done in a clean way that doesn't negatively impact the JVM implementation too much.
  2. Would frozen data need to be portable between the JVM and .net? I'd expect this would be a little tougher, and may require more complex testing.

Relatedly, there's been some recent work to better describe Nippy's own data format with #151.

Happy to answer questions if you have any.

Cheers :-)

luposlip commented

Hi Peter,

Thanks for your swift reply!

If I embark on that journey, I have senior dotnet peeps around me to help me figure out about the types/interfaces.

Ad. 1:
I guess you're right - a fork would be preferable, to keep both implementations clean. Unless the changes are minimal and a few reader conditionals can solve it.

Ad. 2:
Yes, that would be my end goal.

I think I'll look into your code base soon then. Thanks for your input. You may close this issue, if you don't have further input/questions.

Best, H

[UPDATE]: Oh, from the specification issue you referred to, I see that I may even enhance my nd-db library based on the public spec.! 😄

ptaoussanis commented

Thanks for your swift reply!

You're welcome 👍

  1. I guess you're right - a fork would be preferable, to keep both implementations clean. Unless the changes are minimal and a few reader conditionals can solve it.

Re: possible support in Nippy core (i.e. the non-fork option)-

Off the top of my head, the main thing that'd be necessary is an equivalent for DataInput and DataOutput.

Edit to add: there may even be something out-the-box or off-the-shelf for .net. I'm not familiar with the platform, so can't say offhand.

Nippy core's own implementation currently uses those interfaces directly, but one possible idea would be to insert a layer of indirection (e.g. protocol) that could have platform-specific implementations.

I suspect that shouldn't be too invasive, nor impact performance too much.

Could be worth experimenting with, but I'd anyway start with the expectation of a fork and we can look at possibly integrating into core once we know what the fork's implementation looks like.

[UPDATE]: Oh, from the specification issue you referred to, I see that I may even enhance my nd-db library based on the public spec.! 😄

👍 Feedback also welcome on #151 since that feature isn't stable yet, and now would be a good time to still introduce any changes.

You may close this issue, if you don't have further input/questions.

Let's keep it open for now - would also give others an opportunity to chime in with ideas or 👍's if there's public demand.

Cheers :-)

  • 👍1
Bediako commented

Hello. Any updates on this issue? We are in a similar situation and would love to see nippy available for Closure CLR. From our perspective, we would like to see some level or Clojure data structure compatibility across platforms, so that nippy files written in Java could be read by Clojure CLR and vice versa. We are happy to contribute time to make this happen.

Thoughts?

ptaoussanis commented

@Bediako Hi Bediako! No updates from my side- I've never used Clojure CLR so this definitely wouldn't be something to come from me.

I did implement #151 though, and would be happy to consider other adjustments to ease CLR support - but would need someone familiar with CLR to advise on what exactly they'd need from me/Nippy.

Unless someone else has since done work on this, the next (first) step would be for someone to check what facilities CLR has that'd be equivalent to Java's 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.

If it has something that's byte-equivalent, that'd be a big help.

Otherwise (or in the meantime), I'd suggest a data format that's designed for portability in mind - like EDN, JSON, Fressian, etc.

Bediako commented

@ptaoussanis Thanks for the quick reply. We will have a look at Fressian!

  • 👍1