It solves the privacy problem, which is what I originally requested.
If we want multiple versions of the same plugin, we simply need to rename the binary file, for example, CoolPlugin.v1.so, CoolPlugin.v2.so. In the case of LV2, it can also be achieved by editing the URI in the C file before compiling; it's more cumbersome, but possible.
I've learned a lot from this last request.
Thank you very much for solving it, and I intend not to ask for any more features. (I think I've been the most persistent by far XD).
(And speaking of persistent, this is going to be a long-winded explanation, so you can completely ignore it).
I've finally understood that the dependency (and therefore portability) problem is unsolvable as current operating systems are configured. There are partial solutions, and one of them is for hosts to at least keep track of what should be there and notify you if something is missing. (fluidsynth-dssi not only loads sf2, it is also an sf2 host, hence the warning I read in the code about that host rule I was unaware of)
But I've also arrived at a theoretical solution. In addition to the structure based on a category taxonomy (directories), there should be one based on a tag taxonomy to allow multiple relationships and unique element identifications.
Symbolic links are an approach, but they aren't sufficient (as experience shows).
Tag taxonomy has been successful for media management applications. The entire operating system should have incorporated this media management capability long ago.
(When did UNIX emerge? What has changed?).
As long as two IDs are related, it doesn't matter where they are located.
It has also been successful for content management systems like Drupal, or for graphic formatting languages like CSS, where classes are not really classes in the style of programming languages, but rather tags.
Some programming languages support multiple inheritance classes; it's very similar but not exactly the same concept. In multiple inheritance, there is a predefined hierarchy and dependency. However, tags can suggest descendant and ascendant relationships based on context, but they are not predefined. If the ascendant disappears, the descendant retains its identity.
This would also solve the problem of library dependencies... and unsatisfactory solutions like AppImage or Flatpak would no longer be necessary.
Finally, the operating system would be truly free, because it would no longer be bound by hierarchies, but rather driven by fluid relationships (tags), and because the elements would occupy a localized space (directories). However, in nature, space is one of the means of establishing relationships, but it is not a relationship in itself... and from establishing this false equivalence of location = relationship, all these problems arise.
It solves the privacy problem, which is what I originally requested.
If we want multiple versions of the same plugin, we simply need to rename the binary file, for example, CoolPlugin.v1.so, CoolPlugin.v2.so. In the case of LV2, it can also be achieved by editing the URI in the C file before compiling; it's more cumbersome, but possible.
I've learned a lot from this last request.
Thank you very much for solving it, and I intend not to ask for any more features. (I think I've been the most persistent by far XD).
(And speaking of persistent, this is going to be a long-winded explanation, so you can completely ignore it).
I've finally understood that the dependency (and therefore portability) problem is unsolvable as current operating systems are configured. There are partial solutions, and one of them is for hosts to at least keep track of what should be there and notify you if something is missing. (fluidsynth-dssi not only loads sf2, it is also an sf2 host, hence the warning I read in the code about that host rule I was unaware of)
But I've also arrived at a theoretical solution. In addition to the structure based on a category taxonomy (directories), there should be one based on a tag taxonomy to allow multiple relationships and unique element identifications.
Symbolic links are an approach, but they aren't sufficient (as experience shows).
Tag taxonomy has been successful for media management applications. The entire operating system should have incorporated this media management capability long ago.
(When did UNIX emerge? What has changed?).
As long as two IDs are related, it doesn't matter where they are located.
It has also been successful for content management systems like Drupal, or for graphic formatting languages like CSS, where classes are not really classes in the style of programming languages, but rather tags.
Some programming languages support multiple inheritance classes; it's very similar but not exactly the same concept. In multiple inheritance, there is a predefined hierarchy and dependency. However, tags can suggest descendant and ascendant relationships based on context, but they are not predefined. If the ascendant disappears, the descendant retains its identity.
This would also solve the problem of library dependencies... and unsatisfactory solutions like AppImage or Flatpak would no longer be necessary.
Finally, the operating system would be truly free, because it would no longer be bound by hierarchies, but rather driven by fluid relationships (tags), and because the elements would occupy a localized space (directories). However, in nature, space is one of the means of establishing relationships, but it is not a relationship in itself... and from establishing this false equivalence of location = relationship, all these problems arise.
Thank you for everything.