Mad idea: extend DAAP to support writes

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #1801
    rossburton
    Participant

    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

    #12856
    rpedde
    Participant

    @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.

    #12857
    rossburton
    Participant

    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. 🙂

    #12858
    fizze
    Participant

    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.

    #12859
    rpedde
    Participant

    @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.

    #12860
    fizze
    Participant

    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.

Viewing 6 posts - 1 through 6 (of 6 total)
  • The forum ‘Feature Requests’ is closed to new topics and replies.