[CR] BlueSerialization

[bjustice]

View File

BlueSerialization

---

Serialize and deserialize LabVIEW classes using either JSONtext or TOML

Official documentation: https://github.com/justiceb/BlueSerialization

 

---

• Submitter
  bjustice
• Submitted
  08/05/2021
• Category
  General
• LabVIEW Version
  2018
• License Type
  BSD (Most common)

 

[bjustice]

LAVA friends,

Do you like JSONtext?  Do you like LV-TOML?

But do you always wish that either of these libraries supported LabVIEW classes?

Well, with this library, now they do!

The more in-depth documentation can be found at the official source code repo:

https://github.com/justiceb/BlueSerialization

The VIP packages can either be downloaded here, or directly from VIPM.

On a related note, if you like the code, consider checking out the following link:

 

 

[bjustice]

@jdpowell @LogMAN @Antoine Chalons @Aristos Queue

I recommend that you guys take a peak at this code.  We're not normally able to release code like this to the community, but I managed to collect approval for this particular library on grounds that it was very low level and very intertwined with other open-source community code.  (literally recursively entwined with JSONtext lol.)

A few notes:

___

This library leverages the new "LVClass Serializer" input to JSONtext:

Soo, thanks at JDP for adding this input.  Very helpful.

__

Antoine, the TOML serializer here is not yet directly consuming your LV-TOML library.  I would realllly love to make this happen though.

In order to consume LV-TOML, we'll need to add a "LVClass Serializer" input to LV-TOML in exactly the same manner as JDP added this to JSONtext.

For the moment, the TOML code in this library is a branch of the old Erdos Miller TOML library... except that I've added the code required to hook into class deserialization stuff.

__

Logman, I took a look at your recently published "JSONtext Object Serialization" library

https://www.vipm.io/package/pnr_lib_jsontext_object_serialization/

Very cool code!  Your LabVIEW composition library has been quite useful.  In fact, it's a dependency to this library!

So, a big different between your library and this Blue library is that we chose not to use composition for serializing/deserializing classes.  We had a few reasons for this, and it's actually described in more detail on the repo readme.

However, this Blue library ships with a very nifty "BlueVariantView" package.  This exports any LabVIEW data structure to a colorized tree control.  (I was inspired by the LAVA VariantProbe library, so I made my own... but better.)  I used your composition library within this tool to decompose maps, sets, and classes.  Take a look, super cool!

__

Lastly, Aristos, I'll just cryptically say that your an inspiration, and I hope this code benefits you

 

[pawhan11]

Thanks for sharing !

[LogMAN]

Thanks for sharing and kudos to everyone involved!

I did a few tests with a dummy project and it works like a charm. The fact that it provides all the tooling to automate the process is just mind-blowing. It looks like a very powerful tool to save and restore data, with precise control over data migration and versioning.

Also, BlueVariantView - very insightful and handy. Have you ever explored the possibility of manipulating mutation history (i.e. removing older versions)? That could be useful for users with slow editor experience: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015BLnSAM&l=en-US

On 8/6/2021 at 3:48 AM, bjustice said:

So, a big different between your library and this Blue library is that we chose not to use composition for serializing/deserializing classes.  We had a few reasons for this, and it's actually described in more detail on the repo readme.

Fair enough. There are always tradeoffs to tools like this.

Quote

There are some Pros/Cons to this approach. Pros:

• ALL classes in LabVIEW become inherently serializable
• Doesn't require data accessor VIs
• Most closely aligns with the precedent set by JSONtext and other similar serialization libraries

Cons:

• Breaks the LVOOP covenant that private data requires data accessors for access
• Pretty serious security risk. There is no way to protect private data when serializing/de-serializing
• Slow. flatten/unflatten and de(composition) is not cheap

There is one point I would like to address: "Pretty serious security risk. There is no way to protect private data when serializing/de-serializing".

Scope is not the same as security. If you want to secure data, encrypt it.

If you want to serialize only some data, but not all, this is not a security risk but an architectural challenge. You'll find that the same issue exists for the Flatten To XML function. It requires designing classes such that they include only data you want to serialize. A typical approach is to have separate data objects with no business logic.

One point missing in this list is the lack of control over data migration and versioning. My library entirely depends on the ability of JSONtext to de-serialize from JSON. It will fail for breaking changes (i.e. changing the type of an element). Your library provides the means to solve this issue, but it has it's own limitations:

Quote

There are some Pros/Cons to this approach: Pros:

Allows for segregation of serializable and non-serializable data

• Improves read-ability
• Allows user to protect private data from being exposed through serialization
• Allows for the creation of a single future-proof read/write data accessor for the entire "SerializableData" cluster

Cons:

• You have to create the cluster and data accessors → a non-zero amount of work
• Forces users to organize their data into this paradigm
• Will require rework of existing classes wishing to conform to this requirement

There are two points users need to be aware of:

• When de-serializing, Serialized Text must include "Class" and "Version" data, which makes it difficult to interface with external systems (i.e. RESTful APIs).
• Classes must inherit from BlueSerializable.lvclass. This could interfere with other frameworks or APIs.

What makes your library special is the way it handles version changes. We have been doing something similar with regular project libraries, using disconnected typedefs to migrate data between versions. Being able to do the same thing with our objects is very appealing (up to now we have considered them breaking changes and lived with it). I'll certainly bring this up in our next team meeting.

Very cool project. Thanks again for sharing!