<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi, again,<br>
      <br>
      is there any URL where I could POST to suggest streams for
      dir.xiph.org?<br>
      <br>
      <br>
      My users are demanding the ability to add their own stations to
      the app:<br>
      <a class="moz-txt-link-freetext" href="https://marketplace.firefox.com/app/world-radio-player/ratings">https://marketplace.firefox.com/app/world-radio-player/ratings</a><br>
      <br>
      I would like to use their input (with their explicit consent) to
      push data about new streams to dir.xiph.org.<br>
      <br>
      <br>
      On 06/10/2013 07:31 PM, "Thomas B. Rücker" wrote:<br>
    </div>
    <blockquote cite="mid:51B5FF5C.2060807@ruecker.fi" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <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>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Emilis Dambauskas

<a class="moz-txt-link-abbreviated" href="mailto:emilis.d@gmail.com">emilis.d@gmail.com</a>
gsm: +370-686-07732
<a 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>
  </body>
</html>