<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      On 06/10/2013 02:46 PM, Emilis Dambauskas wrote:<br>
    </div>
    <blockquote cite="mid:51B5E6A9.40301@gmail.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">this looks very promising. I see the
        compressed version is now ~250kB.<br>
      </div>
    </blockquote>
    <br>
    Yeah, that's a start and there is probably still some room for
    improvement.<br>
    <br>
    <br>
    <blockquote cite="mid:51B5E6A9.40301@gmail.com" type="cite">
      <div class="moz-cite-prefix"> 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.<br>
      </div>
    </blockquote>
    <br>
    Well, for the moment this is quite experimental.<br>
    <br>
    <br>
    <blockquote cite="mid:51B5E6A9.40301@gmail.com" type="cite">
      <div class="moz-cite-prefix"> Any way, every kilobyte shaved off
        the data transfer or processing time on a mobile phone helps
        very much.<br>
      </div>
    </blockquote>
    <br>
    Yes, that's the reason for this API rewrite in the first place.<br>
    Also more flexible access will help to reduce transfer in favor of
    targeted access.<br>
    <br>
    <br>
    <blockquote cite="mid:51B5E6A9.40301@gmail.com" type="cite">
      <div class="moz-cite-prefix"> I am now waiting for API to get out
        of the experimental state :-)<br>
      </div>
    </blockquote>
    <br>
    I can give you a stable snapshot for your app explicitly, until the
    real API pans out.<br>
    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.<br>
    <br>
    <br>
    Cheers<br>
    <br>
    Thomas<br>
    <br>
    <blockquote cite="mid:51B5E6A9.40301@gmail.com" type="cite">
      <div class="moz-cite-prefix"> On 06/10/2013 08:17 AM, "Thomas B.
        Rücker" wrote:<br>
      </div>
      <blockquote cite="mid:51B56168.4030802@ruecker.fi" type="cite">
        <meta content="text/html; charset=UTF-8"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">Hi,<br>
          <br>
          On 05/22/2013 01:07 PM, "Thomas B. Rücker" wrote:<br>
        </div>
        <blockquote cite="mid:519CC316.8020309@ruecker.fi" type="cite">
          <meta content="text/html; charset=UTF-8"
            http-equiv="Content-Type">
          <div class="moz-cite-prefix">Hi,<br>
            <br>
            On 05/22/2013 12:57 PM, Assen Totin wrote:<br>
          </div>
          <blockquote
cite="mid:CAMrYpX54_VFT1sPSVbGLLTs5N3S5_fo91hspZNU49bxkmUUeHQ@mail.gmail.com"
            type="cite">
            <div dir="ltr">
              <div>
                <div class="gmail_extra">
                  <div>
                    <div>Hi, Emilis, <br>
                      <br>
                    </div>
                    I have two working Icecast players which implement
                    client-side parsing of yp.xml and searching then
                    through it: [...]<br>
                  </div>
                </div>
              </div>
            </div>
          </blockquote>
          <br>
          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. :-(<br>
          This is also bad for users as they have to wait longer for:<br>
          - a large download (700k compressed, 7MByte uncompressed)<br>
          - parsing of the full XML file<br>
          <br>
          Whereas this could be broken down into only delivering the
          necessary data. More requests, less total transfer volume.<br>
        </blockquote>
        <br>
        I've cobbled together something. For now there is only the JSON
        version of the full XML output.<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://api.dir.xiph.org/experimental/full">http://api.dir.xiph.org/experimental/full</a><br>
        <br>
        Note, that I will change the output without notice, but will
        increment the API-revision HTTP header.<br>
        <br>
        Also in case I add more experimental queries, they'll be listed
        automatically at:<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://api.dir.xiph.org/experimental/">http://api.dir.xiph.org/experimental/</a><br>
        <br>
        Notes / known problems:<br>
        - 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)<br>
        - Each stream URL is listed separately for clusters<br>
          - I'll try to return them as an array in the URL field instead<br>
          - clustering doesn't work reliably, this is a legacy code
        limitation for the whole YP and on TODO<br>
        <br>
        Cheers<br>
        <br>
        Thomas<br>
      </blockquote>
      <br>
      <br>
      <pre class="moz-signature" cols="72">-- 
Emilis Dambauskas

<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:emilis.d@gmail.com">emilis.d@gmail.com</a>
gsm: +370-686-07732
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://emilis.info/">http://emilis.info/</a>

-----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+&gt;++ PGP&gt;+ t- 5? X+@ R- !tv b+ DI++++ D+ G e++ h----(*) r+++ y++++
------END GEEK CODE BLOCK------ 

</pre>
    </blockquote>
    <br>
  </body>
</html>