Hi, there.
At my company we have some critical applescript-based solutions that is heavily dependent up on XML Tools.osax to process complex configurations stored as XML. At the same time we are in an urgent need to by more Mac Minis - which need to run those solutions (as clients and as servers). I does not seem to be possible to downgrade the new (space gray) Mac Minis t0 10.13 (we have tried), so they must run MacOS 10.14 Mojave.
(XML-parsing with System Events are far too slow and unstable to be an alternative solution, and I haven’t came across any Script Library than can be used in these specific cases – and we can’t write them ourselves).
The solution we have planned for, in the long term, is to replace the XML with JSON for those configurations. But that will take time, so meanwhile we need a solution that makes it possible to parse xml quickly also on Mojave. We don’t want to turn off SIP, for several reasons.
Now, in this blogpost Shane Stanley describes a temporary solution that would be suitable for us: distributing the osax within the bundle of the app that needs it, compiled in a MacOS-version prior to Mojave.
But we cannot make it work. The applet I made for testing this is code signed, and, yes, the folder within the resource-folder containing the osax is named “Scripting Additions” – with a space.
If I understand Shanes instruction right, the osax itself most be code signed. Is that whats’missing? (I have version 2.9.4 but don’t know how to check if its signed) If so, would it be possible for Late Night Software to provide a code signed version?
Best regards / Jörgen
FWIW, we recently ordered the previous iteration of mac minis and were able to successfully downgrade them to 10.12 and 10.12 for various purposes. I believe you can still purchase those from various outlets.
Right. But that’s would not be a very satisfying solution – investing in so old and relatively slow machines. Also, we don’t know how many machines we will need next month and the month after that.
Correct, but…
No – because it must be signed with the same signature as the finished applet. You will have to sign it.
If you can give some examples of what you want to do, perhaps using AppleScriptObjC and NSXML classes would be a better solution.
Oh, of course…
Once I got a script library from you, Shane, for that purpose (“XML_to_record”), which was very useful in some contexts with small xml:s. But with very large xml:s it gets apparent that it’s slower than XML Tools (in fact it took about 3 times longer to parse the same large xml), so it will slow up the systems I have in mind here and therefore I ruled out that alternative at first. Still, it works and is by far much better than using System Events – so I will reconsider using it.
There are possibly more efficient methods, depending on what you are doing.
Unfortunately I can’t supply any solution or advice. Only some experience.
I had a bunch of ASS apps relying on the Satimage XMLlib OSAX for parsing XMLs.
Now with Mojave they all won’t work anymore.
My problem is that I’m new to ASobjC as well. But while working on the “transfer” I found that working with the NSXML Classes can be very time efficient - even with huge XMLs.
Maybe an example of your problem(s) posted here could help.
Yes I am sure it would be worth the effort to learn how to work with ASobjC. Problem is that I don’t have the time. I’ve got good help with script libraries thru the applescript-users mailing list, although they can’t do everything yet. I’ll see how far that will take me.
I did take the time to learn enough ASObjC to write a few XML related scripts. I’m documenting one on my blog here:
As I did for the Satimage scripting additions, I’ve created an application that embeds the scripting additions for use on Mojave systems. The details are available here:
That’s wonderful news! At least if the slowdown is not too big.
In my case it would mean that the pressure to quickly rebuild our solutions with other ways to process data is reduced.
I’ll try it out.
LNSOSAX really saved my… year, @alldritt.
I have rebuilt some smaller applications processing xml using AsObjC, with help from others. But for a larger solution processing complicated XML:s this was a saviour. At least gives us the respite we need to rebuild this solution.
Also: To my experience, so far, LNSOSAX works as good as the standalone osax – and the processing is not noticeable slower in our context.
So – thanks a lot.