That’s an awesome project, and I really like it! I’d love to be able to use it on my iPhone, but PWAs on iOS are practically unusable due to Apple’s WebKit limitations. After a long search, I finally found a good app: Arpeggi. It’s the only iOS app I’ve found with a really nice interface, and it uses the Open Subsonic API.
I tried Swing Sonic and actually managed to make it compatible with Open Subsonic, but the quality of this translation layer is not very good. It misses scrobbles, metadata, and other features that I find useful.
So I’d like to implement a proper Open Subsonic API for Swing Music with as many features as possible. I see two possible approaches:
First: implement another translation layer from scratch. This is possible, but I haven’t yet thoroughly investigated all the data available through Swing Music’s general API.
Second: implement the Open Subsonic API directly in the Swing Music source code, using direct access to the database and in-memory cache.
The question is: as the project maintainer of Swing Music, which path do you see as preferable? Would you want to support the Open Subsonic API in the project’s core? What are the key considerations regarding implementation architecture and code guidelines? And finally, does it make sense for me to implement the Open Subsonic API for Swing Music and open a PR?
That’s an awesome project, and I really like it! I’d love to be able to use it on my iPhone, but PWAs on iOS are practically unusable due to Apple’s WebKit limitations. After a long search, I finally found a good app: Arpeggi. It’s the only iOS app I’ve found with a really nice interface, and it uses the Open Subsonic API.
I tried Swing Sonic and actually managed to make it compatible with Open Subsonic, but the quality of this translation layer is not very good. It misses scrobbles, metadata, and other features that I find useful.
So I’d like to implement a proper Open Subsonic API for Swing Music with as many features as possible. I see two possible approaches:
First: implement another translation layer from scratch. This is possible, but I haven’t yet thoroughly investigated all the data available through Swing Music’s general API.
Second: implement the Open Subsonic API directly in the Swing Music source code, using direct access to the database and in-memory cache.
The question is: as the project maintainer of Swing Music, which path do you see as preferable? Would you want to support the Open Subsonic API in the project’s core? What are the key considerations regarding implementation architecture and code guidelines? And finally, does it make sense for me to implement the Open Subsonic API for Swing Music and open a PR?