LabVIEW
Get WebDAV Creation Date
@Hooovahh wrote:
Ya know I thought about using one of our generic passwords since it is just a picture right? But no I just mashed the keyboard for the example. But thanks for the comment.
That "fda..." sequence smelled like a left hand keyboard mash. It was hard to imagine you posting a real password, just wanted to make sure.
Search LabVIEW like a graph!
@Hooovahh wrote:
@rolfk wrote:
Basically there is a webDAV property "creationdate" that is supposed to be available in the according WebDAV HTTP XML response. While parsing XML formats isn't really trivial it may have been actually more helpful if the WebDAV extension was built around the HTTPClient library rather than pulling another open source C code into a NI private DLL.
Yes, please NI use more G! I found that page which made me think the API supports it and it just is NI's implementation that is missing the ability. Any help is appreciated.
Leaky abstraction 101...
wiebe@CARYA wrote:
Leaky abstraction 101...
Actually I would say this is the opposite. They abstracted useful features of the underlying service away. I can understand that someone doesn't want to return a potentially huge list of properties from each request that is often never used. But it feels like an omission to not make that list available at least as an optional feature.
@rolfk wrote:
wiebe@CARYA wrote:
Leaky abstraction 101...
Actually I would say this is the opposite. They abstracted useful features of the underlying service away. I can understand that someone doesn't want to return a potentially huge list of properties from each request that is often never used. But it feels like an omission to not make that list available at least as an optional feature.
AFAIC, They made an abstraction (the simplified library), and it's leaking functionality. I'm not sure if that's typically considered a leaky abstraction.
If they'd expose some of the lower level handles, references, etc, or used G (and preferably a class), at least we would be able to extend the library.
As it is, the only options one has is to live with the limitations or to start from scratch.
wiebe@CARYA wrote:
@rolfk wrote:
wiebe@CARYA wrote:
Leaky abstraction 101...
Actually I would say this is the opposite. They abstracted useful features of the underlying service away. I can understand that someone doesn't want to return a potentially huge list of properties from each request that is often never used. But it feels like an omission to not make that list available at least as an optional feature.
AFAIC, The made an abstraction (the simplified library), and it's leaking functionality. I'm not sure if that's typically considered a leaky abstraction.
If they'd expose some of the lower level handles, references, etc, or used G (and preferably a class), at least we would be able to extend the library.
As it is, the only options one has is to live with the limitations or to start from scratch.
Leaky abstraction as I understand it is the opposite. It is when you try to abstract an interface to a system into a generic access interface but then end up exposing much of the implementation details anyhow to the interface user in such a way that the whole abstraction is basically useless as it is again a specialized interface for exactly that service and nothing else anymore.
The only thing needed would be either an extra array of clusters with a property name and property value that can be enabled with an extra boolean. Default it is false to avoid creating potentially huge arrays of data that is never used. Or alternatively have a property access interface on the response handle.
The property value could be simply strings, bonus points for implementing true Variant values here.
One tidbit about using HTTP Client in older LabVIEW versions. In the project I recently did we had the requirement to develop the application in LabVIEW 2013 since it was just a small improvement to the actual application that was developed quite some time ago.
And it worked perfectly on my machine. Then it got installed on a number of computers and the users immediately got the threaded HTTP certificate error about being unable to verify the server. And even disabling the Verification on the HTTP Client:Open Handle.vi did not stop that error from happening.
A little digging showed that the LabVIEW 2013 runtime engine installer did install according versions of NI Curl and NI SSL and even replacing the ca_bundle.crt in the NI Curl folder with a recent version did not help.
Looking on my machine I found that NI Curl and NI SSL were a much newer version 20.0 whereas the version installed by the LabVIEW 2013 RTE installer was 13.0. I took the installer packages for these two components from my "<ProgramData>/National Instruments/MDF/ProductCache" and had them installed on the machines in question and everything was suddenly peachy, even with fully enabled server verification. If you happen to run this on an older system you may also need to add installation of the MS Visual C Runtime 15.0 to the packages to install but on any Windows 10 system that should be already present.
Basically to handle the newer certificate you need a recent installation of NI Curl for the HTTP Client library to work but that also needs an according version of NI SSL. Watchout when looking for the installer packages in the MDF cache. You need a package without the "Real-Time Support" in its name. Those only install support for use of NI real-time targets.
@rolfk wrote:
wiebe@CARYA wrote:
@rolfk wrote:
wiebe@CARYA wrote:
Leaky abstraction 101...
Actually I would say this is the opposite. They abstracted useful features of the underlying service away. I can understand that someone doesn't want to return a potentially huge list of properties from each request that is often never used. But it feels like an omission to not make that list available at least as an optional feature.
AFAIC, The made an abstraction (the simplified library), and it's leaking functionality. I'm not sure if that's typically considered a leaky abstraction.
If they'd expose some of the lower level handles, references, etc, or used G (and preferably a class), at least we would be able to extend the library.
As it is, the only options one has is to live with the limitations or to start from scratch.
Leaky abstraction as I understand it is the opposite. It is when you try to abstract an interface to a system into a generic access interface but then end up exposing much of the implementation details anyhow to the interface user in such a way that the whole abstraction is basically useless as it is again a specialized interface for exactly that service and nothing else anymore.
The only thing needed would be either an extra array of clusters with a property name and property value that can be enabled with an extra boolean. Default it is false to avoid creating potentially huge arrays of data that is never used. Or alternatively have a property access interface on the response handle.
The property value could be simply strings, bonus points for implementing true Variant values here.
It looks like that is what Spolsky was talking about.
So this is simply an incomplete abstraction? Another casualty of fast TTM, pleasing 90% of the crowd, leaving the rest with nothing (but frustration)?
I think I actually prefer a leaky abstraction over an incomplete one.
I hope it will be completed someday... If only there was a way the community could pick this up where it was left...
wiebe@CARYA wrote:I hope it will be completed someday... If only there was a way the community could pick this up where it was left...
With the current state of things at NI I do think there is a small chance that some of these libraries might be eventually githubbed. 😁
NI clearly doesn't have the same drive as they used to have and support for their software is lacking and for toolkit libraries pretty much non-existent nowadays. And they mainly are originally open source libraries that NI took and wrote some LabVIEW compatible wrappers around and then packaged up into a convenient installer. They also made some startup code that does look for dependencies dynamically in the NI Shared directory rather than requiring to throw everything into System32 and risk conflicting with other apps that require a different version of that library to work.
Especially OpenSSL is for instance a library that reserves the right to completely turn their API binary incompatible even between minor revisions and in the past didn't even use a different DLL name for that. Without private copies of it, your application was at the mercy of other installers that might replace the libraries with newer versions and cause your application to crash. Which is also the main reason you need to make sure to use the same version of NI Curl and NI SSL or things will go very badly.
Things will get interesting with added TLS support in LabVIEW 2021 and newer. Now there are a multiple software layers in LabVIEW that all depend on some implementation of NI SSL and that might not always agree as to what version they would like.
@rolfk wrote:
wiebe@CARYA wrote:I hope it will be completed someday... If only there was a way the community could pick this up where it was left...
With the current state of things at NI I do think there is a small chance that some of these libraries might be eventually githubbed. 😁
The silver lining 😊...
I really think NI should (focus on) develop G, and the community should (be enabled to) develop libraries at this level.
Just had a look at the WebDAV protocol and the HTTP Client library is unfortunately not able to handle that either as WebDAV needs other methods that just GET, PUT and POST. Another option bites the dust because of the closed nature of those libraries.
