[Icecast-dev] Radio player for FirefoxOS
emilis.d at gmail.com
Tue Jun 25 03:52:58 PDT 2013
is there any URL where I could POST to suggest streams for dir.xiph.org?
My users are demanding the ability to add their own stations to the app:
I would like to use their input (with their explicit consent) to push
data about new streams to dir.xiph.org.
On 06/10/2013 07:31 PM, "Thomas B. Rücker" wrote:
> On 06/10/2013 02:46 PM, Emilis Dambauskas wrote:
>> this looks very promising. I see the compressed version is now ~250kB.
> Yeah, that's a start and there is probably still some room for
>> My Firefox OS app is using this data on its first run to create a
>> browser-side database of stations. I am currently looking into ways
>> to shorten this process to improve user experience. I am not 100%
>> sure I will be able to supply a snapshot of dir.xiph.org database
>> with the app before the first start, so using the official
>> dir.xiph.org API would be a logical first choice.
> Well, for the moment this is quite experimental.
>> Any way, every kilobyte shaved off the data transfer or processing
>> time on a mobile phone helps very much.
> Yes, that's the reason for this API rewrite in the first place.
> Also more flexible access will help to reduce transfer in favor of
> targeted access.
>> I am now waiting for API to get out of the experimental state :-)
> I can give you a stable snapshot for your app explicitly, until the
> real API pans out.
> But I won't support that ad infinity, basically until you then release
> an updated version for final API and usage of the 'snapshot' tapers off.
>> On 06/10/2013 08:17 AM, "Thomas B. Rücker" wrote:
>>> On 05/22/2013 01:07 PM, "Thomas B. Rücker" wrote:
>>>> On 05/22/2013 12:57 PM, Assen Totin wrote:
>>>>> Hi, Emilis,
>>>>> I have two working Icecast players which implement client-side
>>>>> parsing of yp.xml and searching then through it: [...]
>>>> The idea is to finally offer a better API towards the data. Also to
>>>> reduce the bandwidth usage. The XML file causes a LOT of traffic,
>>>> especially as many clients don't implement HTTP compression. :-(
>>>> This is also bad for users as they have to wait longer for:
>>>> - a large download (700k compressed, 7MByte uncompressed)
>>>> - parsing of the full XML file
>>>> Whereas this could be broken down into only delivering the
>>>> necessary data. More requests, less total transfer volume.
>>> I've cobbled together something. For now there is only the JSON
>>> version of the full XML output.
>>> Note, that I will change the output without notice, but will
>>> increment the API-revision HTTP header.
>>> Also in case I add more experimental queries, they'll be listed
>>> automatically at:
>>> Notes / known problems:
>>> - UTF-8 is broken, badly (this is a problem in the legacy code which
>>> is on my TODO list, for now please ignore the ugliness, or send
>>> patches for the YP code)
>>> - Each stream URL is listed separately for clusters
>>> - I'll try to return them as an array in the URL field instead
>>> - clustering doesn't work reliably, this is a legacy code
>>> limitation for the whole YP and on TODO
>> Emilis Dambauskas
>> emilis.d at gmail.com
>> gsm: +370-686-07732
>> -----BEGIN GEEK CODE BLOCK-----
>> Version: 3.12
>> GAT/CC/MC/GG/O dpu(-) s:+ a C++ UBLHS++ P(+) L+++ E-(++) W+++$ N+ o-- K? !w O? M-@ V? PS+(--) PE Y+>++ PGP>+ t- 5? X+@ R- !tv b+ DI++++ D+ G e++ h----(*) r+++ y++++
>> ------END GEEK CODE BLOCK------
emilis.d at gmail.com
-----BEGIN GEEK CODE BLOCK-----
GAT/CC/MC/GG/O dpu(-) s:+ a C++ UBLHS++ P(+) L+++ E-(++) W+++$ N+ o-- K? !w O? M-@ V? PS+(--) PE Y+>++ PGP>+ t- 5? X+@ R- !tv b+ DI++++ D+ G e++ h----(*) r+++ y++++
------END GEEK CODE BLOCK------
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Icecast-dev