PDA

View Full Version : A folder of our own...



dean
2003-12-16, 21:15
Mac OS X SlimServer users have a folder in their ~/Library folder
called "SlimDevices" that can contain skins, plugins, configuration
files, etc... Other platforms aren't so lucky.

I'm considering consolidating all of our configuration and add-ons to a
single folder that would be placed appropriately on different
platforms.

Typically this folder would be called SlimServer and might contain:

slimserver.conf - our main configuration file
convert.conf - a user modifiable transcoding configuration file
IR - a directory containing add-on IR configuration files
HTML - a directory for skins
Plugins - a directory to store plugins
types.conf - a user modifiable types file
Bin - a directory that can hold add-on command-line binaries for use in
transcoding, etc...
slimserver.db - the ID3 tag cache

the contents of these items would override the default settings for
these files in the folder containing the application.

My thinking is that this folder could be found in several places
according to the appropriate platform:

~/.SlimServer - for unix
/etc/SlimServer - for unix
~/Library/SlimServer - for OS X
/Library/SlimServer - for OS X
My Documents\My Music\SlimServer - for Windows

We'd need to put a little backward compatibility in for existing
installations, but new installs would automatically have the
appropriate folder created at install time.

Thoughts?

-dean

Marius Strom
2003-12-16, 21:20
You might consider prefering /usr/local/etc/slimserver instead of
/etc/slimserver on unix installations. I've been spoiled by FreeBSD's
ports tree, but keeping user-installed apps in /usr/local seems much
more logical to me than polluting the root partition. My $0.02.

On Tue, 16 Dec 2003, dean blackketter wrote:
> Mac OS X SlimServer users have a folder in their ~/Library folder
> called "SlimDevices" that can contain skins, plugins, configuration
> files, etc... Other platforms aren't so lucky.
>
> I'm considering consolidating all of our configuration and add-ons to a
> single folder that would be placed appropriately on different
> platforms.
>
> Typically this folder would be called SlimServer and might contain:
>
> slimserver.conf - our main configuration file
> convert.conf - a user modifiable transcoding configuration file
> IR - a directory containing add-on IR configuration files
> HTML - a directory for skins
> Plugins - a directory to store plugins
> types.conf - a user modifiable types file
> Bin - a directory that can hold add-on command-line binaries for use in
> transcoding, etc...
> slimserver.db - the ID3 tag cache
>
> the contents of these items would override the default settings for
> these files in the folder containing the application.
>
> My thinking is that this folder could be found in several places
> according to the appropriate platform:
>
> ~/.SlimServer - for unix
> /etc/SlimServer - for unix
> ~/Library/SlimServer - for OS X
> /Library/SlimServer - for OS X
> My Documents\My Music\SlimServer - for Windows
>
> We'd need to put a little backward compatibility in for existing
> installations, but new installs would automatically have the
> appropriate folder created at install time.
>
> Thoughts?
>
> -dean
>
>

dean
2003-12-16, 21:24
Interesting, I never knew about /usr/local/etc.

I'm thinking that the server, at startup time, will look through the
list and use the first one it finds. I'll definitely add
/usr/local/etc to the list.

On Dec 16, 2003, at 8:20 PM, Marius Strom wrote:

> You might consider prefering /usr/local/etc/slimserver instead of
> /etc/slimserver on unix installations. I've been spoiled by FreeBSD's
> ports tree, but keeping user-installed apps in /usr/local seems much
> more logical to me than polluting the root partition. My $0.02.
>
> On Tue, 16 Dec 2003, dean blackketter wrote:
>> Mac OS X SlimServer users have a folder in their ~/Library folder
>> called "SlimDevices" that can contain skins, plugins, configuration
>> files, etc... Other platforms aren't so lucky.
>>
>> I'm considering consolidating all of our configuration and add-ons to
>> a
>> single folder that would be placed appropriately on different
>> platforms.
>>
>> Typically this folder would be called SlimServer and might contain:
>>
>> slimserver.conf - our main configuration file
>> convert.conf - a user modifiable transcoding configuration file
>> IR - a directory containing add-on IR configuration files
>> HTML - a directory for skins
>> Plugins - a directory to store plugins
>> types.conf - a user modifiable types file
>> Bin - a directory that can hold add-on command-line binaries for use
>> in
>> transcoding, etc...
>> slimserver.db - the ID3 tag cache
>>
>> the contents of these items would override the default settings for
>> these files in the folder containing the application.
>>
>> My thinking is that this folder could be found in several places
>> according to the appropriate platform:
>>
>> ~/.SlimServer - for unix
>> /etc/SlimServer - for unix
>> ~/Library/SlimServer - for OS X
>> /Library/SlimServer - for OS X
>> My Documents\My Music\SlimServer - for Windows
>>
>> We'd need to put a little backward compatibility in for existing
>> installations, but new installs would automatically have the
>> appropriate folder created at install time.
>>
>> Thoughts?
>>
>> -dean
>>
>>

Marius Strom
2003-12-16, 21:26
Linux distributions typically use /etc/whatever, but all the BSD's (that
I deal with at least) prefer /usr/local/etc/whatever, which seems more
logical to me.

On Tue, 16 Dec 2003, dean blackketter wrote:
> Interesting, I never knew about /usr/local/etc.
>
> I'm thinking that the server, at startup time, will look through the
> list and use the first one it finds. I'll definitely add
> /usr/local/etc to the list.
>
> On Dec 16, 2003, at 8:20 PM, Marius Strom wrote:
>
> >You might consider prefering /usr/local/etc/slimserver instead of
> >/etc/slimserver on unix installations. I've been spoiled by FreeBSD's
> >ports tree, but keeping user-installed apps in /usr/local seems much
> >more logical to me than polluting the root partition. My $0.02.
> >
> >On Tue, 16 Dec 2003, dean blackketter wrote:
> >>Mac OS X SlimServer users have a folder in their ~/Library folder
> >>called "SlimDevices" that can contain skins, plugins, configuration
> >>files, etc... Other platforms aren't so lucky.
> >>
> >>I'm considering consolidating all of our configuration and add-ons to
> >>a
> >>single folder that would be placed appropriately on different
> >>platforms.
> >>
> >>Typically this folder would be called SlimServer and might contain:
> >>
> >>slimserver.conf - our main configuration file
> >>convert.conf - a user modifiable transcoding configuration file
> >>IR - a directory containing add-on IR configuration files
> >>HTML - a directory for skins
> >>Plugins - a directory to store plugins
> >>types.conf - a user modifiable types file
> >>Bin - a directory that can hold add-on command-line binaries for use
> >>in
> >>transcoding, etc...
> >>slimserver.db - the ID3 tag cache
> >>
> >>the contents of these items would override the default settings for
> >>these files in the folder containing the application.
> >>
> >>My thinking is that this folder could be found in several places
> >>according to the appropriate platform:
> >>
> >>~/.SlimServer - for unix
> >>/etc/SlimServer - for unix
> >>~/Library/SlimServer - for OS X
> >>/Library/SlimServer - for OS X
> >>My Documents\My Music\SlimServer - for Windows
> >>
> >>We'd need to put a little backward compatibility in for existing
> >>installations, but new installs would automatically have the
> >>appropriate folder created at install time.
> >>
> >>Thoughts?
> >>
> >>-dean
> >>
> >>

kdf
2003-12-16, 21:36
Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:


> ~/.SlimServer - for unix
> /etc/SlimServer - for unix
> ~/Library/SlimServer - for OS X
> /Library/SlimServer - for OS X
> My Documents\My Music\SlimServer - for Windows
>
> We'd need to put a little backward compatibility in for existing
> installations, but new installs would automatically have the
> appropriate folder created at install time.
>
> Thoughts?
Where would it install by default, and what mechanism creates the files in the
home (~) directories? the db file can be very large so it would seem wasteful
to just duplicate it. Maybe the db should stay in /etc...or perhaps the music
folder. Copy conf files to ~/.Slimserver when a new user runs the server for
the first time to allow custom settings (even custom music folders). The trick
comes when upgrades add new settings, and you want to upgrade the new defaults
without killing the custom settings.

-kdf

Roy M. Silvernail
2003-12-16, 21:58
On Tuesday 16 December 2003 23:15, dean blackketter wrote:

> I'm considering consolidating all of our configuration and add-ons to a
> single folder that would be placed appropriately on different
> platforms.

I like the idea of /etc/SlimServer. It feels nice and *nixy. Many packages
are turning up configured like this, too. (Apache and postfix come to mind)
I'm already using /etc/slimserver.pref.

But I don't think I'd put anything other than configurations and databases
in /etc/SlimServer. /etc is traditionally for configuration files alone (and
real *nix bigots would say it should be /usr/local/etc, because it's not part
of the standard install). Extra binaries (those that aren't already on the
$PATH somewhere), plugins and skins, I think, would be more appropriate
in /usr/local/SlimServer, along with the rest of the server's perl code and
associated binaries.

This also depends on whether SlimServer is being installed as a system service
or a user's tool. If it's a user install, I'd be happy with the whole
shooting match in ~/.SlimServer.

> We'd need to put a little backward compatibility in for existing
> installations, but new installs would automatically have the
> appropriate folder created at install time.
>
> Thoughts?

install-whack.pl to move existing installs up to the unified structure? I'm
leaning toward defining SlimServer as a system service and standardizing
on /etc/SlimServer/ for configs and /usr/local/SlimServer/ for runtimes (for
*nix...OS X has a traditional binaries and configs location, I'm sure, and
Windows... well, it's always been a bit ad hoc, I s'pose... x:\Program
Files\SlimServer?).

Roy M. Silvernail
2003-12-16, 22:03
On Tuesday 16 December 2003 23:20, Marius Strom wrote:
> You might consider prefering /usr/local/etc/slimserver instead of
> /etc/slimserver on unix installations. I've been spoiled by FreeBSD's
> ports tree, but keeping user-installed apps in /usr/local seems much
> more logical to me than polluting the root partition. My $0.02.

On thinking about it, I like /usr/local/etc better myself. Good point.

Dan Sully
2003-12-17, 05:36
* Marius Strom <marius (AT) marius (DOT) org> shaped the electrons to say...

> You might consider prefering /usr/local/etc/slimserver instead of
> /etc/slimserver on unix installations. I've been spoiled by FreeBSD's
> ports tree, but keeping user-installed apps in /usr/local seems much
> more logical to me than polluting the root partition. My $0.02.

I think this is a bad idea. One should not assume that everyone has root.

-D
--
The Lottery: a tax for people who can't do the math.

seanadams
2003-12-17, 09:24
It's a convention that changes with time for every platform....
apache's a good example. It used to be all the conf stuff would go in
/usr/local/etc/, binaries in /usr/local/bin, but then someone said why
not put the binaries, icons etc in there and a lot of installations
started using /usr/local/apache - I seem to recall that's the default
now if you build from source, and personally I like having it all in
one place.

So, I submit: /usr/local/SlimServer for Unix.



On Dec 16, 2003, at 8:26 PM, Marius Strom wrote:

> Linux distributions typically use /etc/whatever, but all the BSD's
> (that
> I deal with at least) prefer /usr/local/etc/whatever, which seems more
> logical to me.
>
> On Tue, 16 Dec 2003, dean blackketter wrote:
>> Interesting, I never knew about /usr/local/etc.
>>
>> I'm thinking that the server, at startup time, will look through the
>> list and use the first one it finds. I'll definitely add
>> /usr/local/etc to the list.
>>
>> On Dec 16, 2003, at 8:20 PM, Marius Strom wrote:
>>
>>> You might consider prefering /usr/local/etc/slimserver instead of
>>> /etc/slimserver on unix installations. I've been spoiled by FreeBSD's
>>> ports tree, but keeping user-installed apps in /usr/local seems much
>>> more logical to me than polluting the root partition. My $0.02.
>>>
>>> On Tue, 16 Dec 2003, dean blackketter wrote:
>>>> Mac OS X SlimServer users have a folder in their ~/Library folder
>>>> called "SlimDevices" that can contain skins, plugins, configuration
>>>> files, etc... Other platforms aren't so lucky.
>>>>
>>>> I'm considering consolidating all of our configuration and add-ons
>>>> to
>>>> a
>>>> single folder that would be placed appropriately on different
>>>> platforms.
>>>>
>>>> Typically this folder would be called SlimServer and might contain:
>>>>
>>>> slimserver.conf - our main configuration file
>>>> convert.conf - a user modifiable transcoding configuration file
>>>> IR - a directory containing add-on IR configuration files
>>>> HTML - a directory for skins
>>>> Plugins - a directory to store plugins
>>>> types.conf - a user modifiable types file
>>>> Bin - a directory that can hold add-on command-line binaries for use
>>>> in
>>>> transcoding, etc...
>>>> slimserver.db - the ID3 tag cache
>>>>
>>>> the contents of these items would override the default settings for
>>>> these files in the folder containing the application.
>>>>
>>>> My thinking is that this folder could be found in several places
>>>> according to the appropriate platform:
>>>>
>>>> ~/.SlimServer - for unix
>>>> /etc/SlimServer - for unix
>>>> ~/Library/SlimServer - for OS X
>>>> /Library/SlimServer - for OS X
>>>> My Documents\My Music\SlimServer - for Windows
>>>>
>>>> We'd need to put a little backward compatibility in for existing
>>>> installations, but new installs would automatically have the
>>>> appropriate folder created at install time.
>>>>
>>>> Thoughts?
>>>>
>>>> -dean
>>>>
>>>>

Richard Purdie
2003-12-17, 10:10
I'm all for creating a directory of config files. On unix I would search:

~/.SlimServer
/usr/local/etc/SlimServer
/etc/SlimServer

in that order.

I'm sure you'll add a command line option to force the server to use a
certain directory and override the defaults.

I hear what others have said about the cache file but I think it
overcomplicates things. Not many people run two copies of the server and
someone can easily hack the server code if it really bothered them. There
are all kinds of issues about sharing it between two processes as well...

This has reminded me that there is one more tweak needed to the cache
system. A timer needs to be set to call saveCacheDB once an hour to save any
chances made to the database that didn't occur though the initial scan or a
rescan.

Has anyone been using the caching code? If so how does it perform?

RP

Caleb Epstein
2003-12-17, 10:14
On Tue, Dec 16, 2003 at 11:58:45PM -0500, Roy M. Silvernail wrote:

> But I don't think I'd put anything other than configurations and
> databases in /etc/SlimServer. /etc is traditionally for
> configuration files alone (and real *nix bigots would say it should
> be /usr/local/etc, because it's not part of the standard
> install). Extra binaries (those that aren't already on the $PATH
> somewhere), plugins and skins, I think, would be more appropriate in
> /usr/local/SlimServer, along with the rest of the server's perl code
> and associated binaries.

If you're going to use /etc then use /usr not /usr/local

I'd personally suggest /usr/local/etc/slimserver and
/usr/local/share/slimserver, with StudlyCaps as appropriate.

Any files that could grow (e.g. logs, database) should go in /var or
/usr/local/var

References: http://www.pathname.com/fhs/

--
Caleb Epstein | bklyn . org | No act of kindness, no matter how small,
cae at | Brooklyn Dust | is ever wasted.
bklyn dot org | Bunny Mfg. | -- Aesop

kdf
2003-12-17, 14:18
Quoting Richard Purdie <rpurdie (AT) rpsys (DOT) net>:


> Has anyone been using the caching code? If so how does it perform?

I've been using it. CPU usage rails at startup, but it still loads faster
overall than the odl style scan. I haven't been looking in great detail, but I
recall seeing a few odd "deleting" messages even when the mp3's haven't been
altered. Most seem to be in regards to cover.jpg. Works well overall tho, so
it hasn't caught my attention enough to dig deeper :)

cheers,
kdf

Andrew Arensburger
2003-12-17, 15:25
On Wed, 17 Dec 2003, Sean Adams wrote:
> It's a convention that changes with time for every platform....
> apache's a good example. It used to be all the conf stuff would go in
> /usr/local/etc/, binaries in /usr/local/bin, but then someone said why
> not put the binaries, icons etc in there and a lot of installations
> started using /usr/local/apache - I seem to recall that's the default
> now if you build from source, and personally I like having it all in
> one place.
>
> So, I submit: /usr/local/SlimServer for Unix.

How about just

${PREFIX}/bin
${PREFIX}/etc
${PREFIX}/share
...

and let the installer decide whether ${PREFIX} should be /, /usr/local,
/opt/SlimServer, or whatever?

--
Andrew Arensburger Actually, these _do_ represent the
arensb (AT) ooblick (DOT) com opinions of ooblick.com!
Generic Tagline V 6.01

Roy M. Silvernail
2003-12-17, 15:34
On Wednesday 17 December 2003 07:36, Dan Sully wrote:
> * Marius Strom <marius (AT) marius (DOT) org> shaped the electrons to say...
>
> > You might consider prefering /usr/local/etc/slimserver instead of
> > /etc/slimserver on unix installations. I've been spoiled by FreeBSD's
> > ports tree, but keeping user-installed apps in /usr/local seems much
> > more logical to me than polluting the root partition. My $0.02.
>
> I think this is a bad idea. One should not assume that everyone has root.

That's why I had mentioned the system service vs. user application aspect. It
may be safer to assume that an installer has root these days, given the
number of "personal" *nix systems we have now. (anyone else remember when
dixie.com was one of the very few?), but there should be two distinct routes
of installation: system and user. The system install can use /usr/local/*.
The user install can use ~/.SlimServer/*.

Jack Coates
2003-12-17, 21:21
On Tue, 2003-12-16 at 20:20, Marius Strom wrote:
> You might consider prefering /usr/local/etc/slimserver instead of
> /etc/slimserver on unix installations. I've been spoiled by FreeBSD's
> ports tree, but keeping user-installed apps in /usr/local seems much
> more logical to me than polluting the root partition. My $0.02.
>
....

Unfortunately, the FHS suggests something from left field that I've
never seen used (/etc/opt/slimserver, see
http://www.pathname.com/fhs/2.2/). However, current Linux philosophy
seems to lean toward /etc/appname, while from-source portable code tends
to use /usr/local/etc or /opt/appname/etc. My vote is to use
/etc/slimserver for the RPMs, but /usr/local/etc/slimserver in the
Perl-source tarball.
--
Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
************************************************** ********************
* "We both said I love you, the Shriners loaned us cars, we raced up *
* and down the sidewalk twenty thousand million times." *
* -- She's An Angel by They Might Be Giants *
************************************************** ********************

Jack Coates
2003-12-17, 21:26
On Tue, 2003-12-16 at 20:36, kdf wrote:
> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>
>
> > ~/.SlimServer - for unix
> > /etc/SlimServer - for unix
> > ~/Library/SlimServer - for OS X
> > /Library/SlimServer - for OS X
> > My Documents\My Music\SlimServer - for Windows
> >
> > We'd need to put a little backward compatibility in for existing
> > installations, but new installs would automatically have the
> > appropriate folder created at install time.
> >
> > Thoughts?
> Where would it install by default, and what mechanism creates the files in the
> home (~) directories? the db file can be very large so it would seem wasteful
> to just duplicate it. Maybe the db should stay in /etc...or perhaps the music
> folder. Copy conf files to ~/.Slimserver when a new user runs the server for
> the first time to allow custom settings (even custom music folders). The trick
> comes when upgrades add new settings, and you want to upgrade the new defaults
> without killing the custom settings.
>
> -kdf

Again looking at the FHS and its effect on Linux distributions, this
sort of thing has been moving to /var, theory being that it is volatile
user data, but the users will never access it directly. Examples include
/var/www/html, /var/lib/pgsql, /var/lib/nagios.

I'm not terribly thrilled with it there, but nevertheless, that's what
they've been doing for years now. Again, that's the way to go for RPMs
IMHO. This is a helpful doc for packaging nicely for RPM-based
distributions: http://www.linux-mandrake.com/en/howtos/mdk-rpm/
--
Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
************************************************** ********************
* "There was a shopping mall, now it's all covered with flowers, *
* if this is Paradise I wish I had a lawnmower." *
* -- (Nothing But) Flowers from Sand in The Vaseline by The Talking *
* Heads *
************************************************** ********************

Jack Coates
2003-12-17, 21:35
On Wed, 2003-12-17 at 20:26, Jack Coates wrote:
....
> Again looking at the FHS and its effect on Linux distributions, this
> sort of thing has been moving to /var, theory being that it is volatile
> user data, but the users will never access it directly.

"This sort of thing" == the database file in this case, along with any
locks, sockets, socks or lockets that might be required :-)
--
Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
************************************************** ********************
* "It doesn't matter if it's good, it only matters if it rocks!" *
* -- Rock Your Socks By Tenacious D *
************************************************** ********************

Robert Moser II
2003-12-18, 23:22
kdf blurted out:
> Quoting Richard Purdie <rpurdie (AT) rpsys (DOT) net>:
>>Has anyone been using the caching code? If so how does it perform?
> I've been using it. CPU usage rails at startup, but it still loads faster
> overall than the old style scan.

I'd say that it's a good thing for it to rail at startup, that shows
that it isn't being I/O bound, and is actually working hard.