Quoting ron thigpen <[EMAIL PROTECTED]>:
> also, wouldn't this increase overhead for system resources to load > multiple instances of all the server bits? well, I think I'm just getting the impression that demands for how this must work will end up causing the one instance to double up on so much already. Its a given that once such a feature is created, there will be a user out there who will demand that it works in every different way possible. Share some files, not others, share prefs, not others. User defined access to players, swappable on the fly, admin lockouts etc. Just about any feature you name will have at least one person who will say that its absolutely required. The idea of two separate servers just cuts to the chase, though admittedly bars shared libraries on the fly. You'd have to use symlinks. > i'm thinking of multiple libraries all being in the same database, just > with tracks having a reference to the library that they belong to. it all depends on how much isolation is required to satisfy the majority of users. It may be enough to simply obey user permissions on a per-directory basis. A bit complicated on systems that dont really have very good multi-user permission control. > in my mind, it's more like building in a new upper level bit of metadata > (like "genre") and then building the UI to support this structure. most > functions could work exactly as they do now, except that calls to the > track database would have an extra WHERE clause for library filtering. > > server settings would be common to all users but with limited access to > administration i think that's probably ok. and per-player settings are > already supported. I agree in principle. I think I'm just gunshy after hacking my way through a miserable attempt to handle multiple folders (bug 607). Just trying to make snse of that was headache enough to keep me from pondering any effort on my part on the code for this kind of change. > right-o on the one machine preference (or zero, truth be known). no > reason why each library couldn't be hosted centrally and share one SS > instance. some libraries could be expected to go offline and online > (laptop, portable drive or player). server would have to detect this, > but previous scans could be preserved in the DB if the device/path were > uniquely recognized. true enough. part of my thinking was also influence by the current server limit on db access. sqlite can't handle concurrent connections, so a single db is a thing of the future. Right now, this discussion has no timeline, so my main angle was something near term. eventually mySQL use will allow this kind of thing. > ok. glad to know i'm (we're) not making you crazy. i don't know that > my vision of how this would work is the best, but it does seem possible. > and i am willing to wait for a really kickass implementation. > > oh, willing to work within the limits of my time and capabilities. good to know. I'm not fully into this side of things myself. A lot of the db stuff is out of my league. In the interest of disclosure, I think my personal motive is avoiding a monstrously complex beast that is trying too hard to give everything to specific individuals and spreading too thinly on the core design requirements. Of course, I don't know exactly what those are, so I tsick with my own sense of confusion as a limit. It was a full-time job keeping on top of all the activity. Since I already have a full-time job, I gave up on keeping up with every path. :) -kdf -kdf _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
