It would be useful to have a new DOpusRT /info flag, for example pathstxt, which provides a compact text output for paths instead of XML.
The current XML output works well, but it becomes quite verbose when many tabs are open. A lightweight delimiter-separated format would be much smaller and easier to process, especially for WM_COPYDATA communication with external tools such as AutoHotkey.
The format could use a fixed field order, for example:
Parsing XML is not that slow. Are you doing something where the difference would really matter?
Does it really matter how compact it is when it's being parsed by code? Using a standard format like XML instead of a bespoke one makes it easier for code to read the data.
I did a small benchmark using my actual data structure and parsing code.
The XML data was about 13.8 KB, while a simple pipe-delimited format was about 5 KB.
Using my current XML parsing function (MSXML DOM + node/attribute processing + object creation), the average parsing time was about 4.6 ms. With a simple pipe-delimited text format, the average parsing time was about 0.16 ms.
The absolute difference is still only a few milliseconds, but the text format was 28 times faster in this test.
For small amounts of data such as ListSel, the XML overhead is practically negligible. The benefit of a compact format is mainly for larger data sets.
A compact format would make the implementation simpler, require less parsing code, and could reduce both transfer overhead (including WM_COPYDATA) and parsing overhead.
It looks like your overhead is actually in your XML parser then, rather than being intrinsic to the format itself.
Does AutoHotkey not have a decent XML parser and have to use ActiveX?
I imagine that if it's for AutoHotkey, what you should really be looking for is a way to do it through dopuslib.dll.
You are probably right that my benchmark measures the overhead of my current XML parsing approach (MSXML DOM + node/attribute processing), rather than XML format itself.
As far as I know, AutoHotkey does not include a built-in XML parser, and using MSXML through COM seems to be a common approach. There may be other libraries or methods, but my main focus was the simplicity of the data format and the overhead involved in processing it.
Using dopuslib.dll may be another possible approach, but improving the existing DOpus interface directly would probably be a better solution.
For my current case, I was mainly considering whether a simpler data format could reduce unnecessary parsing and transfer overhead.
Yes, that's fair. I mainly suggested a simpler format to simplify the data exchange and parsing code, with some minor performance benefits as well. It would only require adding a flag. Seems like a relatively simple feature request?
The point is that everytime you add some feature to a software component, it has costs.
A direct one, to implement it (with the potential side effects on configuration), test it, document it, and so on.
And it also has an indirect one to maintain it in the future, ensure it remains compatible with future additions to the overall software itself (not to mention regression risk when implementing it).
So, when the value added by the feature is low, it's often not that good of an idea to go further.
From my pov, the request here is very niche, it has no real value :
Performance wise, the processing times remain at a very low level
The ease of parsing is not obvious as parsing XML is already such a common task
I don't see that as an important improvement on Opus features. I'd personnaly prefer the Opus team to work on other things that can add value to Directory Opus zon a broader level ... but I am not the one to decide
Another reason not to implement the format you've asked for is that it is not extensible. There's no way to add new data fields to each item without breaking the format and anything currently using it.
It's not just complexity on the developer side, either. Every extra option adds complexity for users trying to work out how to do things. Things that get added need to do something that makes enough of a difference to offset things like that.
Have you tried using a XSLT filter on the XML instead of whatever-you-are-using-to-parse-xml-currently ?
Even if you're using MS's crappy built-in(?) xslt parser; i'm sure you can get it to output fast enough.
I've a photography client who I help with that kind of stuff every 18 months or so when he forgets how his scripts work, they digest many thousands of records this way - v. large photo shoots you see.
The changing path could be placed first, while the other attributes could remain fixed: path | active_lister | active_tab | lister | side | tab.
@opless
Thanks for the suggestion. I haven't looked into XSLT in depth. My current XML parsing approach was basically adapted from someone else's code, so I don't have much experience with it.
Maybe it would be nice to have a simpler output format...
I would understand if, instead of a random output format, you'd suggest something like JSON, because JSON requires almost no effort to parse, and is globally used and supported.
FWIW, I'm not against your request, just suggesting that while you wait, you can think of alternatives. Note that we don't know your actual use case where speed is so important that a few ms matter. At least your own benchmark doesn't support your request.
I'm not an expert in AutoHotkey, but my bet is that by completely omitting XML parsing, you can get better times if you use regex on the plain response instead.
Another option that I think would be even more useful is a simple command for sending a custom message to a specified HWND.
It could even support the Evaluator: SendCustomMsg 26286408 {=viewmode=}
Here 26286408 is an AutoHotkey HWND. This would make it possible to send dynamically generated values directly to an external application, rather than being limited to path output.
