> Mike, have your worked on that stuff any more since you sent that
> patch?
All I've done with the patch lately is sync it up with 0.4.0.
It's a pretty simple patch ... my goal was merely to allow for a bit of
accountability with regards to people in our department skipping other
people's queued tracks. :) Plus it's nice to see who queued what.
However, that being said, I think it'd be pretty easy to add some toggles
to obs.conf to control whether a user can skip other people's requests and
other global things like that (perhaps a limit on how many songs one
person can have in the play queue at once?).
As far as ACLs go, how does this sound for an implementation? (BTW, I
haven't looked at the new 0.5 code yet, so I'm not sure whether this is
practical for the new multiple-streams stuff.)
I came up with this breakdown of the various "powers" that an Obs user
has:
Play Queue
----------
Queue songs
Delete own songs
Delete other songs
Reorder queue
Skip currently playing song
Playlists (would this include the new channels?)
---------
Create playlists (ability to maintain own playlists is implied)
Alter playlist that belongs to someone else
DJ Random sets
--------------
Create DJ Random sets
Add and delete from DJ Random sets
Change active DJ Random set
Administrative
--------------
Alter song, album, artist data
Controls on these powers would be implemented using a user permissions
table in the DB, where each username is listed along with a series of
boolean fields corresponding to the above permissions (one could use
MySQL's SET field type here, but it's not really portable to other DBs).
A setting in obs.conf should also define default permissions for users not
appearing in the permissions table (this way, people who have no need for
these ACLs or authentication in general can ignore the whole thing).
With this, setting up the private playlists should be just a matter of
adding a few fields to the Playlist table (a "Creator" field and a
bitfield or something to store whether users besides the creator can read
and/or alter the playlist).
If you want more finegrained control of playlists, perhaps a "playlist
user permission table" would be in order: each row would contain the
playlist number, the user name, and the aforementioned read/write
bitfield. This would probably override the setting in the Playlist table
(so it could be used to add users from an otherwise restricted playlist or
block certain users from an otherwise open playlist).
And, of course, all the changes to the interface code to implement these
controls :)
The next thing I was planning on working on was a voting system (that
would optionally use the login information to eliminate multiple votes as
well as nifty things like personal favorite songs lists). However, I'm
still mulling over a nice way to turn those votes into a basis for
weighted random song selection.
Anyhow, you'll find my patches at
<http://mike.quintero.staff.noctrl.edu/patches/obs/>
along with some brief documentation regarding the changes. In particular
note that the additional userdata fields are not automatically added by
the install-db.pl script. Usual disclaimers apply for this stuff; also
realize that I haven't tested any of it with the 0.5.0 stuff from CVS.
However, we've been using this patch here at NCC for about two months
without any hitches.
Mike Quintero
Information Technology Services
North Central College, Naperville, IL
email: [EMAIL PROTECTED] phone: (630)637-5442
_______________________________________________
Obs-dev mailing list
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/obs-dev
