Simplify YamlDotNet assembly names? about yamldotnet HOT 12 CLOSED

I and aaubry have been talking about extracting the serialization feature out of RepresentationModel into its own assembly. In other words, there will be two assemblies, YamlDotNet.RepresentationModel and YamlDotNet.Serialization.

Imo, YamDotNet.Core is fine as long as there's documentation to direct library users.. which there isn't, but that is also on the to do list.

from yamldotnet.

Oh, I was expecting more to shrink everything to a single assembly instead of expanding it! As it is often the case for this kind "low level" library (managing a file format like YAML)...

For example, if you check the details of nuget downloads:

• for Core: 9926 downloads
• for RepresentationModel: 9450 downloads
  So 95% of the time, users want to serialize/deserialize YAML. This kind of figures should hit you and make you realize how YamlDotNet is really used - and want to be used, no? One YamlDotNet.dll assembly to rule them all! :P

But ok, this is easy to fix on our own branch, so not a huge problem again.

from yamldotnet.

The name "RepresentationModel" comes from the YAML specification, but I agree that it is not very intuitive.

Regarding merging the code into a single assembly, I am not sure of what is the best move. As @rogernorling mentioned, we were thinking of splitting even more the assemblies, but your arguments also make sense. If we look at Json.NET, for example, everything is in a single package.

The separation in two assemblies was initially made so that the port of LibYAML was on one project, Core, and the higher-level functionality was on another. At the time the library was distributed as a zip containing both assemblies, so I did not question that separation. When I created the NuGet packages, I created one package for each assembly for no particular reason. Another option would have been to create a single NuGet package containing both assemblies.

from yamldotnet.

I understand. I'm evaluating to use a YAML library to use it at work for our project as well probably in my SharpDX project. As we have to manage several third parties API (and we can't use nuget), I tend to prefer having as few as assemblies (less access on the disk when loading them...etc., for things like Mono on Android, this can little help perf). We are usually IL merging this kind of separated assemblies (or repackaging them if we have access to the sourcecode). That's why I'm looking a bit obsessed here ;)

In fact, I first tried YamlDotNet, but when I discovered two assemblies (and some limitations in the API - spotted in issues - would be glad to contribute to them), I started to look for a more compact YAML lib. So I forked YamlSerializer (with some work on this fork to upgrate it to PCL), was quite happy with the simple API (two entry points, XamlNode and Serializer) and particularly impressed with the code, but not as nice and clean code as YamlDotNet... and lately, doing some perf tests, discovered that It was also 3-4 times slower than YamlDotNet (and 3 times more RAM! Their parse is not really optimized, while being very closed to 1.2 specs), so I'm back evaluating YamlDotNet. You know the story now ;)

From an internal pov, I understand your original - implicit - reasons (LibYAML...etc.) but from a user perspective, I believe that a more pragmatic approach would be to provide a single assembly (my obsession is back, sorry :)

Anyway, hope you understand my concerns more clearly. I appreciate the quality of code of YamlDotNet so far. Keep up the good work!

from yamldotnet.

Just my two cents... I tend to agree with @xoofx about the merge into a single assembly... This seems to be the standard with other format/serialization libraries (NewtonSoft JSON, Protobuf.NET). The distinctions can (and probably should) still be maintained in the form of namespaces, but from a user perspective a single DLL seems much simpler.

from yamldotnet.

I have consulted other people and they all agree that it would be better to merge YamlDotNet.Core and YamlDotNet.RepresentationModel into a single assembly / package, called YamlDotNet. I think we should do this.

from yamldotnet.

I could take the time to give you pull requests for this since I already manipulated the test assemblies while doing refactoring. However, should we merge the test assemblies as well?

from yamldotnet.

That would be good. Regarding the tests, I'm not sure of what could be the
best approach. Is it useful to keep them in different assemblies ?
On Oct 2, 2013 1:41 PM, "Roger Norling" [email protected] wrote:

I could take the time to give you pull requests for this since I already
manipulated the test assemblies while doing refactoring. However, should we
merge the test assemblies as well?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-25534976
.

from yamldotnet.

The "lazy" approach would be to keep it as is since the test assemblies aren't included in the releases. The logical approach would be to merge them since that would follow the one test assembly per production assembly guideline. Separate assemblies could help a little tracking dependencies, but that's more like a bonus side effect. Up to you I guess..

from yamldotnet.

I agree. For now let's keep them separate since this avoids spending time
that could be better applied to other tasks.
On Oct 2, 2013 8:09 PM, "Roger Norling" [email protected] wrote:

The "lazy" approach would be to keep it as is since the test assemblies
aren't included in the releases. The logical approach would be to merge
them since that would follow the one test assembly per production assembly
guideline. Separate assemblies could help a little tracking dependencies,
but that's more like a bonus side effect. Up to you I guess..

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-25567606
.

from yamldotnet.

Good news! I actually already did the merge on my branch but as I'm moving the library to PCL, It can't really push it back to master, as there are still lots of things to fix in the Serialization part. I don't know if you are interested in a PCL support?

from yamldotnet.

This one can be closed, right?

from yamldotnet.