2009-07-08, 07:28
Having written MR and taken the venue of nfo files and the like I have come to the conclusion that this route is painful and essentially requires the user to rescan his collection more or less completely every time changes are supplied from the external application.
I have taken a look at the SQLite implementation an it seems straightforward enough to abandon the whole nfo business and patch into the database directly. Philosophically I do not subscribe to the .NET coding, nor platform specific code which is why I don't really see myself contributing to the current XBMC design. Cross-platform wise I believe and sort of C++/CLI code is flawed bt I do not want to get into a philosophical discussion.
I have been fascinated by UMM but the project seems to be going nowhere and ergo am looking into writing the server as is on a container platform but on one end there is still the XBMC database. I can only see myself on this end writing consumers that directly modify this database while evolving the current MR project into a web services platform using likely a RESTful API. I know I am sort of breaking the mold here and going off on a tangent but there is no general movement so why not kick the tires and give it a shot?
Here is where it gets down to the direct modification of the SQLite tables while maintaining the existing schema for now.
What is the official policy here: Are update/Delete SQL a no-no or do you see a level of tolerance for this? I can see this going out of sync on a release level but at least for the duration of a release something media-server like would emerge (which cannot be said for the current state of UMM affairs). It would also relieve XBMC from any licensing restrictions due t he decoupling of the code.
Back to the question: Do you utterly resist the SQlite update?
As for the forum I am posting this in: None of the forums seemed fit for applying this, it's neither an XBMC development ticket, independent of UMM, really and a support-like question but independent o platform. So before getting flamed I had to pick some location and this was it. Transfer as you deem appropriate.
I have taken a look at the SQLite implementation an it seems straightforward enough to abandon the whole nfo business and patch into the database directly. Philosophically I do not subscribe to the .NET coding, nor platform specific code which is why I don't really see myself contributing to the current XBMC design. Cross-platform wise I believe and sort of C++/CLI code is flawed bt I do not want to get into a philosophical discussion.
I have been fascinated by UMM but the project seems to be going nowhere and ergo am looking into writing the server as is on a container platform but on one end there is still the XBMC database. I can only see myself on this end writing consumers that directly modify this database while evolving the current MR project into a web services platform using likely a RESTful API. I know I am sort of breaking the mold here and going off on a tangent but there is no general movement so why not kick the tires and give it a shot?
Here is where it gets down to the direct modification of the SQLite tables while maintaining the existing schema for now.
What is the official policy here: Are update/Delete SQL a no-no or do you see a level of tolerance for this? I can see this going out of sync on a release level but at least for the duration of a release something media-server like would emerge (which cannot be said for the current state of UMM affairs). It would also relieve XBMC from any licensing restrictions due t he decoupling of the code.
Back to the question: Do you utterly resist the SQlite update?
As for the forum I am posting this in: None of the forums seemed fit for applying this, it's neither an XBMC development ticket, independent of UMM, really and a support-like question but independent o platform. So before getting flamed I had to pick some location and this was it. Transfer as you deem appropriate.
