[Icecast-dev] Radio player for FirefoxOS

["Thomas B. Rücker"]

Hi,

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


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


Cheers

Thomas

> On 06/10/2013 08:17 AM, "Thomas B. Rücker" wrote:
>> Hi,
>>
>> On 05/22/2013 01:07 PM, "Thomas B. Rücker" wrote:
>>> Hi,
>>>
>>> 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.
>> http://api.dir.xiph.org/experimental/full
>>
>> 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:
>> http://api.dir.xiph.org/experimental/
>>
>> 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
>>
>> Cheers
>>
>> Thomas
>
>
> -- 
> Emilis Dambauskas
>
> emilis.d at gmail.com
> gsm: +370-686-07732
> http://emilis.info/
>
> -----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------ 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/icecast-dev/attachments/20130610/17ffb501/attachment.htm