- This topic has 5 replies, 3 voices, and was last updated 17 years, 2 months ago by
.
-
Posts
-
I just had a mad idea, whilst thinking about the future direction of Sound Juicer (the GNOME CD ripper) and so on. How about extending the DAAP protocol to make it possible to upload new songs? Then people like me who run firefly on a NAS would be able to rip directly into the store, instead of going via a NFS/CIFS/etc mount.
As I said, mad idea. But if Firefly supported it, I’d add support to Sound Juicer. 🙂
Ross
@rossburton wrote:
I just had a mad idea, whilst thinking about the future direction of Sound Juicer (the GNOME CD ripper) and so on. How about extending the DAAP protocol to make it possible to upload new songs? Then people like me who run firefly on a NAS would be able to rip directly into the store, instead of going via a NFS/CIFS/etc mount.
As I said, mad idea. But if Firefly supported it, I’d add support to Sound Juicer. 🙂
Ross
How would you propose such a thing work? My only objection would be that then you have a potentially internet-listening daemon that writes to the file system… that makes me kind of scared. As much or more so than just being exposed to the net generally, as it would only take a protocol exploit to write to the file system rather than some more difficult like a buffer overflow.
That said, I’d definitely like to have read/write tags at some point, so I might be headed down that road anyway.
Obviously there are security concerns, it would have to be disabled by default, require authentication and so on. I don’t actually know what DAAP looks like at the protocol level, so I cant give any thoughts about that.
As I said, just a mad idea. 🙂
Leave the physical file-i/o out of the equation and its still a nice feat.
There have been some scripts hacked together that filled the DB with metadata for songs in a /incoming directory, or similiar.So I guess functionality to add a distinct file that does not reside within the mp3_dir should be doable, possibly via a XML request.
Then the actual DB insert could be handled by mt-daapd.This could be neatly combined with a file upload mechanism through the webinterface at a later point, if necessary.
@fizze wrote:
Leave the physical file-i/o out of the equation and its still a nice feat.
There have been some scripts hacked together that filled the DB with metadata for songs in a /incoming directory, or similiar.So I guess functionality to add a distinct file that does not reside within the mp3_dir should be doable, possibly via a XML request.
Then the actual DB insert could be handled by mt-daapd.This could be neatly combined with a file upload mechanism through the webinterface at a later point, if necessary.
See, but the file system scan does that, so what’s missing, really? A scan request for a single file? Hrm… and you think file uploads via post?
Hrm.
Well, the file does not necessarily hold all the meta-data. So I guess that would be a means to “push” the meta-data into the DB along with the file-tag.
Letting the meta-data aside, yes, it would boil down to a single file-scan request.
A single-file metadata-update request would come in handy too, I guess, if somewhen the webinterface would be capable of managing tags and such.
- The forum ‘Feature Requests’ is closed to new topics and replies.