> It can't be discoverable if it doesn't exist ...
That's great, and for some things the court can ask you "Well *why* haven't you got it?" and then you're fucked. Now you're explaining in front of a parliamentary committee why you destroyed what would turn out to be evidence.
"Our standard process is to only retain logs when legally required to, either due to being notified about a litigation or through legally mandated periods" is a fully complete sentence.
Unless you're required to retain logs for some reason like a litigation hold or legally or contractually mandated retention period and you violate those, while the adversarial party might be annoyed at you for not retaining logs there isn't much they can or will do beyond being annoyed.
Of course if you destroy logs after being notified of litigation or inquiry, you're gonna have a bad day.
> "Our standard process is to only retain logs when legally required to, either due to being notified about a litigation or through legally mandated periods" is a fully complete sentence.
And for some of that, the "legally mandated period" is "since the beginning of time itself".
If you automatically delete everything after the statutory retention period, you're fine. If you conditionally do so, that's when you have explaining to do.
> It can't be discoverable if it doesn't exist ...
This cuts both ways. I've seen plenty of litigation go south because one side had evidence and the other side had nothing because they deleted/shredded/lost the proof.
Most places I've worked in the last few years don't have logs greater than 12 months, and some even only retain logs for 1-3 months. Apart from specific 7+ year legally mandated systems for things like financial records.
Looking at the vendor page for that 5K colour camera, the page directly says they only support Windows and macOS. :( :( :(
> The Arcturus Vision apps include Arcturus Vision Camera for recording and playing 5K HDR spatial video, Arcturus Vision Gaussian XR for exploring 3D Gaussian splats, and Sync for transferring recordings to Windows or Mac (with conversion for other players on Mac).
It's an open Linux box, using standard interfaces. You can use ffmpeg and scp to transcode and transfer, or whatever else you're comfortable with. Even if Arcturus provided an app, most Linux users probably wouldn't use it.
Seems like someone got updated KPIs and decided to try the most ham-fisted enshittification move to raise registrations. Oh, it is now possible again to see about five top reviews per item. Seems like loss of traffic was rough.
> mature code generation support for all relevant languages.
Heh, "relevant languages" is kind of an interesting term there. If the relevant language is Java then sure, it's fine.
Some popular modern languages (ie Go) don't have good SOAP support (yet). At least not to the point of being able to point them at WSDL/XSD specs and have everything auto-generated. :(
That seems like a Go problem. I don't exactly love SOAP and WSDL, but it was the default choice for Java and .Net 10 - 15 years ago in enterprise applications. Given the complexity, rewriting it a few years late, just to switch from a perfectly functional SOAP API to REST makes no sense and would mean that you either run two stack, or force every integrator to rewrite their software.
That's just no how the real world works. When this was launched Go probably wasn't a relevant language, Rust probably barely existed and the whole thing was designed for a corporate setting, where Java and .Net are the standards. All those who are asking "Why SOAP?" or suggests replacing it seems rather naive about how most corporate software is sold, designed, built and maintained, as well as expected lifetimes of solutions.
Eg Python is barely trudging along with random forks of a library that stopped being supported 10 years ago, each fork only getting maintained for about a year at a time.
I really think outside of Java and c#, soap is totally dead.
I think that‘s a matter of days and few hundred dollars in tokens to port it to Go if you really need it.
Porting is where AI can do a really good job with the right instructions.
It's more than just a few days of effort though. Sme of the members of my team at work have been working on adding SOAP 1.1 support. It's a significant amount of time and effort though.
> WSDL/XSD specs in this case seem to be incomplete or just wrong.
Are you meaning in my comment, or in the GitHub repo the article references?
Asking because AFAIK the theory of having (accurate) vendor provided WSDL/XSD files is that you can generate a bunch of code (ie parsers, strong validation) that works with it, generate tests. There are additionally well developed SOAP specific GUIs (ie www.soapui.org) which will directly load the WSDL/XSD files and let you immediately make test network calls to validate things.
Though sure, you can do the above manually without WSDL/XSD files, but if you have accurate ones provided to you by vendors then it makes things a lot easier.
Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Which is also my experience too.
Or have you not dealt with decade+ long services with severe inertia/lockin? Because that is what lets them get away with this.
> Are you not reading the thread where people with direct experience with these specific backends are noting the WSDLs either are not accessible or don’t match the actual services?
Correct, yes I haven't.
Other members of staff where I'm working are from Java backgrounds, and have described (in detail) WSDL/XSD (when things are accurate) in positive terms as I put above.
And yeah, I'm presently dealing with vendor specs/docs that don't match what's actually sent over the wire, and it's a huge pain in the arse. And the vendor doesn't give a shit, as like you allude to they're in the telco business so the lock in aspect you mention is correct to. :(
reply