I think Steffan's proposal is interesting. At first I couldn't figure out
what he was proposing but its clearer now. However it may be more complex
and have some hidden issues that need to be well understood.
Avuton's points are also very valid, there are many ways to do most of what
Steffan has proposed. Although I think setting up an nfs link is a little
harder than he claims (I would not let my wife try to do it, the support
would overwhelm me. . . ). I also would like to see MPD kept as simple as
possible, the best way to keep software reliable.
I also like Max's idea for a "client-server" way to have MPD instances find
each other automatically and connect to content stores. I'm currently doing
this with Avahi (Bonjour-Zeroconfig) and NFS. It works pretty well (but
sometimes spontaneously breaks and some routers seem allergic to it). It
also requires a lot of infrastructure setup on each machine its on. Steffan
proposal is closer to a peer to peer version of the same thing. I would
advocate for using existing protocols whereever possible when dealing with
networking or file systems. The potential traps for something new are
enormous.
The issues to be addressed I think are:
1) Security. If this isn't really well thought through MPD could very
quickly become persona-non-grata everywhere.
2) Since this is about sharing the database and the content some other
issues around the database (extended tags and cover art for example) must be
planned for or it will be a complete reset for all the work that would be
done in the future.
3) Sharing. Is this a way to share libraries with others? That is loaded as
well. No one needs an RIAA lawsuit.
4) Moving content out of the local network runs into bandwidth issues real
fast. Most of the content I'm concerned with is FLAC and some starts as very
high bit rate files. That won't work over an external network very easily.
And there are still the security issues going to the outside world. MPoD on
the iPod however does have a feature for using the MPD protocols to push
your content to your iPhone wherever you are.
5) Syncronizing multiple clients in the same house is critical. If the
clients are more than a few milliseconds out of sync it becomes very
annoying.
Be careful that this doesn't turn into a Slimserver (squeezecenter,
squeezeboxserver this month) clone. They have already solved many of these
problems (benefits of have a major corporate sponser to fund). But its
gotten pretty complex and the Logitech marketing guys are driving it (who
have no clue who the users are or why they would buy a Squeezebox). The
point being to get really clear about what problems you intend to address
how to most simply address those problems and minimize the unintended
consequences.
To that end I would like to see something like Max's proposal, that
automatically connects an authorized MPD client instance to an MPD Host (MPD
instance with connected library of content, clear names will really help
here) and make the content available. If the two can be syncronized in
playback (like squeezeboxes) that would be very helpful. If extended
databases can be created and shared that's even better. Important is to not
break existing implementations unless there is a clear migration path or
there will be a lot of unhappy users. If two instances of MPD are sharing
with each other there are issues of duplication of content and issues of
looping endlessly as local vs. remote get blurred.
Demian Martin
Product Design Service
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
