@sansp00 wrote:
I vote for a api so that people with more free time can use it and develop their own plugin, just to keep Ron working on the important stuff ( the FF core ) and leave the outside enhancements to others to play with.
Working on it. I have output plugins already, I’ll have db plugins soon, and that’s where this would go.
I don’t see online radio as a that off the mark. Just to be the devils advocate, Slim has it, so why could we ?
Because that’s what slim *does*. It’s single-stream sever-side pushed content. It’s a different idea alltogether. It has one output stream that you manage centrally. You decided what it plays, and it has a single firehose output that clients can hook up to. Smart server, dumb clients.
The daap concept is exactly opposite. Dumb server that just gives clients the location of media files, and a rock stupid web server to allow the clients to fetch them.
The “right” way to do with mt-daapd is to have those streams point to another program that does stream transocoding. That’s the unix way. Do one thing well.
Stream transcoding is another thing. And vlc already does it well.
The other stuff, is mail reader which could use the roku display for other purposes should be put be kept out ( more for technical reasons, I don’t want to it to be binded to Roku ). But even outside FF, I would keep in streamlined with FF like a product suite of some sort.
That was more along the lines of joke on Zawinski’s law, but there’s more proof.
— Ron