network filesystem level exposition. Use an existing network
filesystem. read only or read-write, to expose either the entire
database or only portions of the metadata as files that the client can
request ALA SMB, TFTP, HTTP, etc.
Use cases:
Read Only:
User can view album art, lyrics, metadata, or whole songs, depending on
server settings.
read/write:
User can upload new songs, album art, lyrics, etc.
Cost:
Library: gotta use an existing library. something mature, production
ready (see above). More required libraries for runtime and build time
Port: Most technologies require a separate port. Server can reply with
hostname et port for raw data server. Many people believe a separate
port adds complexity.
Benefits:
Library: By using a library, implementation is more simple. Not
reinventing a new wheel, and dealing with debugging, etc. Security is
already provided (optionally) and shorter total ttl for new features.
Port: New read/write feature set can be made to be centralized. I have
several MPDi, but only one library. Each MPD should redirect to one
master (This use case needs some more improvements, BTW. Why do I still
have to refresh each MPD when I add a song?) Existing protocol only
needs one minor adjustment. client requests rw data server, gets a
response, connects. No request, no response, no broken clients.
(speaking of response, does the mpd protocol have inbuild versioning yet?)
Isolation: Because the new data is over a new port, and possibly a new
thread, etc. a crash or instability in the new protocol isn't going to
be disruptive to existing services during the testing and development
phase. Possibly developed as an optional "Companion Server" (mpdcs).
Additionally, If an existing protocol is usurped (http primarily), an
optional plugin can be provided for existing httpdi to reduce
implenentation overhead in large or complex environments.
On 3/5/2012 15:58, Andy Kelley wrote:
On Mon, Mar 5, 2012 at 3:36 PM, Steven Blackburn <st...@beeka.org
<mailto:st...@beeka.org>> wrote:
GrooveBasin is an interesting idea and already looks quite smart.
Thanks! :)
I would be wary of adding library management to it though - it is
the thin end of a very thick wedge (e.g. will it correct the tags
and add album art).
Actually... that is on the roadmap. Suggested tag corrections,
possible song duplicates, misc. library cleanup, etc.
Library management is a must-have feature for me - it's definitely on
the roadmap. Bliss looks interesting, but I would like users to go
through minimal effort of setting up this media player in order to
have this feature. It's already somewhat complicated, since you have
to install both GB and mpd. I would like to avoid adding a 3rd
component if possible.
I've already been pestering Max about whether a patch that adds
ability to edit tags would be welcome or not.
What you are proposing could also duplicate file management
functions that may already be present on a server (e.g. Bliss). I
presume GB would have to place the file somewhere on the local
disk for MPD to find it. I would be inclined to keep the files in
that "upload" folder and ask MPD to add that to the library... MPD
will then give you lists of albums / artists for the GB user
interface (is the folder structure exposed?). The user can then
tidy the files by hand / choosen library manager if they wish.
I keep toying with the idea of trying to add album art support to
the MPD protocol, which would make GUIs like this look more
user-oriented. I saw this on a wish-list somewhere... is there a
high-level design / thoughts on how this would be done?
Steve.
On 5 March 2012 23:12, Andy Kelley <superjo...@gmail.com
<mailto:superjo...@gmail.com>> wrote:
Yes. It makes sense because mpd is acting as the authority on
tag data, so to have the script be *another* tag-reader would
result in inconsistencies and duplicated code.
On Mon, Mar 5, 2012 at 3:01 PM, Max Kellermann
<m...@duempel.org <mailto:m...@duempel.org>> wrote:
On 2012/03/05 23:54, Andy Kelley <superjo...@gmail.com
<mailto:superjo...@gmail.com>> wrote:
> If mpd supported reading tags for arbitrary files, not
just files that have
> already been added to the database, I could choose the
correct destination
> for the file before mpd adds it to the database.
So what you want to do is use MPD as a "tag reading
daemon" for your
script?
Max
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft
developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5,
CSS3, MVC3,
Metro Style Apps, more. Free future releases when you
subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
<mailto:Musicpd-dev-team@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
