@Kevin, I hope my response won’t sound like beginning of some argument. I understand you present the case from the point of view of Apple product and DTS engineers and I appreciate very much your input and everything you post here. However, I really feel an urge to comment on some of the points you made in your latest post. I'm trying to present the point of view of a small independent developer, who adopted Finder Sync API for certain reasons and built some software around it.
As a general, rule this kind of language in our documentation should be read as "use it for this, don't use it for other things".
I don’t know how the documentation “should be read”, I just know that to me it sounds like not putting limitations on usage of Finder Sync API to remote content/data syncing only. I may be wrong about it, but my estimation is that the current ratio of still maintained third party applications embedding Finder Sync extensions is about 6 to 7 agains 1 in favor of those, which don’t do anything related to remote content/data syncing (and that includes all content/data syncing applications before they adopted File Provider API). I think that says enough about how developers outside Apple understood the scope of usage for Finder Sync API. I understand that intentions of Apple engineers might be different, but the reality is quite different and Finder Sync API has created the whole ecosystem of third party applications embedding these extensions, which do nothing related to remote content/data syncing.
I'm well aware that the extension point was used for much broader use cases, but I also think it was pretty clear from the APIs general behavior that it wasn't really designed for that.
I have to disagree with “it was pretty clear from the APIs general behavior that it wasn't really designed for that” here. Again, it doesn’t matter what the intention was, it matters how people actually use it. Most of them see and use it as a way to extend Finder’s “capabilities”. Let me try to elaborate even further…
Finder Sync API is rather small and simple. It consists of two classes (one acting only as an abstract class, meant to be subclassed and used as the entry point to extension execution) and one protocol. All of them comprise of less than a dozen of methods. None of those methods has to do anything with syncing remote content/data. While almost every class and method name, as well as their functionality, in File Provider API clearly shows API's intended use scope, the whole Finder Sync API is about monitoring local directories (that Finder “enters” and “exits”), adding badges to icons displayed in Finder and adding menu items to files selected in Finder. Nothing, absolutely nothing of this is in any way related to syncing remote data/content. The only thing related to (any kind of whatever) syncing in Finder Sync API is its name. The methods in the API simply “beg” to be used to add Finder functionality with icon badges and additional menu items. And like I’ve pointed it out at the beginning of this long reply, it seems that the vast majority of developers use it that way.
… but the reality is that the FinderSync extension is not a particularly "good" part of the current system.
I don’t know the internals of the current system to comment whether Finder Sync extension is “good part” of it or not. All I’m trying to say is that Apple, apparently unintentionally, created the whole ecosystem of applications using the API outside of its “originally intended” scope, just because the scope wasn’t clearly communicated (I still maintain that strong opinion), neither in the documentation, nor in the API functionality.
As a general mechanism for extending the Finder, it's never been a particularly good solution, as that's a role that it was simply never designed to fulfill… While that may be true at a surface level, anyone whose actually tried to use it as a general "expansion" mechanism will very quickly notice that it significant issues and limitations.
I agree with the examples you've stated here, but as a third part application developer, I think Finder Sync does a pretty good job in extending Finder’s functionality, apart from some obvious things (some of which you mentioned), like two or more extensions fighting over which one will present its icon badge if they monitor same directories and, as mentioned, inability to monitor certain folders ``(/Applications,iCloud Drive, actually ~/Library/MobileDocuments and some others). There are some points of improvements and I’ve already filed some bugs/requests, but they seemed to be completely ignored (some for years) and now, seeing how Apple engineers see Finder Sync API and how it "should be used", I’m not surprised.
The fact is, Finder Sync API scope of usage is way broader than Apple initially intended (apparently). It seems the vast majority of developers see it as a way to extend Finder’s functionality. Therefore, if it isn’t “good part” of the system, PLEASE make it so (whatever that means). Or if you don't want or it isn't possible to do and you want to deprecate and discontinue it, PLEASE provide “good part” replacement with the same (and possibly more) functionality. The minority of Finder Sync extensions currently available on the market are and will be migrating to File Provider API, because they can and that API is meant for them. But if Finder Sync API is gone, the rest majority of available Finder Sync extensions will die with it as well.
After all, the vibrancy and longevity of a computing platform depends on the availability of versatile third party software solutions. I think it’s in nobody’s interest to kill something (without providing equivalent replacement) that contribute to that vibrancy and versatility.
…but the most useful thing you can do here is filing bugs and enhancement requests describing what you're actually doing and how you'd like things to work. This is the point to document what you're doing and why it's important so the engineering team can make the right decisions about how this should work going forward. Bugs are critical here, as they provide they're the concrete documentation the engineering team uses to decide what to prioritize and focus on.
I completely agree with this and I've already filled a few bugs enhancement requests for Finder Sync API, but so far they have been ignored. However, I will continue doing so. However, the initial reason for this thread is not any functionality of Finder Sync API, but the missing settings for those extensions in System Settings application in Sequoia. I've filed such bug/enhancement request already, FB15249290. So far, it's been completely ignored for more than 10 days, I haven't been notified whether at least it's a duplicate of some other request.
