Thanks for your comment and explanation! Perhaps we are mixing up two different topics. I am absolutely in favor of creating separate packages for meta data extraction (sorry for my misleading last comment), to handle everthing interface based to allow for extension / replacement like in the search package. But we have to decide on the basis for media handling (not only meta data storage) in Neos. Do we “just” want to add meta data to the assets e.g. via the CR or any other data storage? Or do we want to use the CR as the basis for asset storage and asset handling in Neos. If I did not misunderstand his comment, @aertmann mentioned the second solution as a possibility in this post about media package and search / meta data.
Solution 1 is more or less what you think of I guess. One major problem I see is the context. You have to provide the service with the asset and the current context in order to get the correct node properties for the dimensions, workspace etc. But I think it does not make sense to make a service interface that requires a context (which is CR specific) if we want to generalize. For me it feels more “natural” to use a node that already knows about its context in the first place.
To me it makes absolutely sense to have DataExtractors or configurable meta data sources (Alfresco etc.). But I do not quite see the use case for different storages. I am not against it, I just don’t see the use case for now.
Solution 2 is probably more complex. We could use nodes also for tags etc. We could use the node tree for navigation or nested tags. And we already have search / elasticsearch for nodes for advanced search and filtering. As such it has nothing to do with meta data handling, although the nodes could be used for meta data storage easily. With this solution, the Neos.Media package would include the node based asset storage. So my last comment was misleading, sorry for that. It’s not about packing meta data functionality in a media browser package, it’s about providing a different (node based) kind of asset handling.
As I thought of solution 2 when talking about node based storage, I initially proposed the intermediary solution, as solution 2 seems quite complex to me.
Sorry, I guess my initial RFC has not very much to do with the things we are discussing now… I don’t know if this thread is the right place to discuss all this, I feel like spoiling the thread with all my questions. Happy to use other channels like Slack if you think that’s more appropriate. 