If you're interested in working with me let me know. We can connect on
github. I can see building this as a now playing kit, that works out of the
box, and comes with examples and configurations for different webservers. We
could even add a liquidsoap module for those that want to trigger updates
off meta data events.
On Mon, Sep 26, 2011 at 10:05 PM, okay_awright <[email protected]>wrote:
> If you were personally asking me the question, I must admit that I really
> don't know how it will turn out performance-wise in this configuration :)
> But I love that JSONP idea, it's clean, it would be a pity to throw it out
> anyway.
>
>
> On 27/09/2011 03:40, Brandon Casci wrote:
>
>> Would a light background bash script that curl's the output to disk every
>> so many seconds be a good comprise until you have a load worth considering a
>> server side http cache? The static file can be served by icecast, apache,
>> nginx or whatever the preferred web server is.
>>
>> Sent from my iPhone
>>
>> On Sep 26, 2011, at 9:27 PM,
>> okay_awright<okay_awright@**ddcr.biz<[email protected]>>
>> wrote:
>>
>> Hi!
>>> Just a thought, I once measured the benefits of serving short-lived
>>> static files against dynamically generated server responses under heavy
>>> loads in a similar context. It appeared that if the server generating
>>> the response isn't able to properly cache its answers, performances
>>> degrade very fast.
>>> The easiest solution was to store the server response on disk, only
>>> once, whenever there was a change (e.g. maybe writing a plain JSON after
>>> a track change), so you can let a fast static-content webserver like
>>> Nginx, or a cache server like Varnish perform their job. Even if this
>>> file only lives for a few minutes, it can help.
>>>
>>> --
>>> best regards,
>>>
>>> okay_awright
>>> <okay_awright AT ddcr DOT biz>
>>> [PGP key on request]
>>>
>>> On 26/09/2011 21:43, Brandon Casci wrote:
>>>
>>>> Sorry for the delay. I'm going to post something to github today or
>>>> tomorrow. It's different than I described. A JSONP solution. Basically
>>>> you
>>>> place an XSL template on the icecast server that will spit out it's now
>>>> playing info as a JSONP response. Then on your website, you have
>>>> something
>>>> like jquery make a JSONP call to that url, and you can write the
>>>> response to
>>>> the web page however you lilke. It's a simple solution. It might have
>>>> scaling problems if you have a lot of listeners on your now playing page
>>>> at
>>>> one time, but this is probably good for most small broadcasters.
>>>>
>>>
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-**d2dcopy1<http://p.sf.net/sfu/splunk-d2dcopy1>
>>> ______________________________**_________________
>>> Savonet-users mailing list
>>> Savonet-users@lists.**sourceforge.net<[email protected]>
>>> https://lists.sourceforge.net/**lists/listinfo/savonet-users<https://lists.sourceforge.net/lists/listinfo/savonet-users>
>>>
>>
> --
> best regards,
>
> okay_awright
> <okay_awright AT ddcr DOT biz>
> [PGP key on request]
>
--
=========================================
Brandon Casci
Loudcaster
http://loudcaster.com
=========================================
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users
