LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Pure LabVIEW JSON Web Token (JWT) Library (Use on VxWorks, Linux, Windows, etc)

Thank you, very nice! I rolled my own JWT (it's not that complex), but have not yet got it working with the GoogleAPI. I'll take a look at your code!

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 11 of 22
(610 Views)

There's also a google auth API on VIPM from me...

~ Helping pave the path to long-term living and thriving in space. ~
0 Kudos
Message 12 of 22
(599 Views)

Well, a base oauth system using my web server and a gmail auth.

~ Helping pave the path to long-term living and thriving in space. ~
0 Kudos
Message 13 of 22
(598 Views)

@IlluminatedG wrote:

 

The serialization integration no longer exists though. At this point I'm convinced serialization is the devil. But a whole new 100% LabVIEW replacement for LV Web Services exists 😄


Serialization is not evil. It is dearly needed whenever you want to transmit complex systems across a serial stream interface. But it gets very quickly evil as you start adding new features, datatypes and state models. Every one needs more special cases and exception code handling.

 

And then you come to the glorious idea to try to persist dynamic state across the serial stream and you are in the fangs of the 9 headed monster of your nastiest night mares. 😂

Rolf Kalbermatter
My Blog
Message 14 of 22
(574 Views)

There was definitely a bit of facetiousness in there. Currently digging out of the throes of wrangling serialized data version mutations due to a decision that was made that wasn't ever really tested and hoooooo boy edge cases on edge cases, all without having the processes in place up front. And of course when you merge from multiple devs which set of class mutation history do you keep?

~ Helping pave the path to long-term living and thriving in space. ~
0 Kudos
Message 15 of 22
(553 Views)

Are you actually merging classes in GIT?
Can that be done?  Certainly not with the embedded mutation history.

That does sound chaotic

0 Kudos
Message 16 of 22
(542 Views)

I changed to store the version in the serializable data now and stopped relying on class mutation versions since LabVIEW uses them for its purposes which definitely don't align with trying to manage config formats heh.

 

But we're about to move away from serialization completely and have a standard structure so that file layouts aren't changing with refactors.

~ Helping pave the path to long-term living and thriving in space. ~
0 Kudos
Message 17 of 22
(527 Views)

I solve the versioning at a different level.

 

When reading the configuration I read the version.

 

If it's an old version, I convert it to the newer format, iteratively (1->2, 2->3, 3->4, etc.). There could be warnings if the are breaking changes, or when going backwards.

 

After that, the configuration matches the expected data, and each object is serialized by recursively filling each object. I don't use the object's version at all.

 

When there are plug ins involved, I let each module upgrade itself. So there's a global version for the global settings and file structure, and when loading a module, the module gets a change to upgrade the data before it gets serialized.

0 Kudos
Message 18 of 22
(517 Views)

Makes sense to me.

I was always a bit skeptical on how that library would get used.

It was fun to figure out the project provider plugin stuff though.

And I don't think I would have figured out the class mutation stuff without having access to AristosQueue.

 

Good luck over there!  Looking forward to New Glenn soon

0 Kudos
Message 19 of 22
(504 Views)

wiebe@CARYA wrote:

 

If it's an old version, I convert it to the newer format, iteratively (1->2, 2->3, 3->4, etc.). There could be warnings if the are breaking changes, or when going backwards.


That's exactly the current technique. One of the main issues even after keeping up with the mutation is the dependency management pains that can show up when the classes backing the config are shared across many large SW platforms. Normally it wouldn't be a huge ordeal but these are SW stacks with multiple hundreds of serialized classes and things can get refactored across classes or moved into new classes and the combinatorics of it all just turn into a mountain of maintenance because of course we don't get it right the first time or the fifth time sometimes. There are extenuating circumstances with the architecture and inheritance hierarchy here that make it much more difficult to manage than it needs to be. And those configs need to be shared across languages so you've multiple times the maintenance effort. It's just a readable version of flattened classes as strings with all of the drawbacks that come with that and only the readability "fixed".

~ Helping pave the path to long-term living and thriving in space. ~
0 Kudos
Message 20 of 22
(492 Views)