<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://reviewboard.asterisk.org/r/2715/">https://reviewboard.asterisk.org/r/2715/</a>
     </td>
    </tr>
   </table>
   <br />





 <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I am not a fan of having to include the uriparser as a dependency. The biggest reason is that this introduces a prerequisite for a core feature that is not actually used anywhere in Asterisk.

I also just don&#39;t think it&#39;s necessary. The only URI parsing that really should be necessary is to separate the scheme from the rest of the URI. Right now, when allocating a bucket or bucket file, you grab the last element of the path to use as the bucket or bucket file name. I don&#39;t see the point in doing this because:

1) I don&#39;t foresee a situation where just the final path element will be useful to a scheme. I&#39;m betting that the full path (or heck, even the full URI) will be much more useful.
2) It&#39;s possible to have multiple buckets with identical names within the same scheme. This means that in order to differentiate buckets (in, say, debug messages), you&#39;ll have to use the full URI.
3) The bucket-&gt;name and file-&gt;name are never referenced in the core bucket code except to set the values.

I say that if you want to store anything other than the scheme of a URI in a bucket or bucket file, then just store everything after the &#39;:&#39; or &#39;://&#39; in the name field so the individual scheme implementations can do what they need with the data. However, even that&#39;s not really necessary since the full URI is retrievable via ast_sorcery_object_get_id().</pre>
 <br />









<p>- Mark</p>


<br />
<p>On August 19th, 2013, 3:54 p.m. UTC, Joshua Colp wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Asterisk Developers.</div>
<div>By Joshua Colp.</div>


<p style="color: grey;"><i>Updated Aug. 19, 2013, 3:54 p.m.</i></p>









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
Asterisk
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Bucket is a generic file and directory API implemented as a thin wrapper over sorcery. It decouples the storage of files from the backend and provides the ability to set metadata on file themselves. What it means to have files in a &quot;bucket&quot; and details about the files themselves is left up to the user of the bucket API. It enforces no restrictions. Identification of things is done using URIs, which include a scheme. Modules implement specific schemes (local, for example) and take care of the implementation specific aspect of it. The ability to get bucket and file information in a JSON format is provided, as is the ability to copy and move files.

Stuff to focus on:

1. Is the API sane and complete?
2. Do the unit tests cover everything?
3. What do we want to do for URI parsing - I wrote a basic extremely optimistic one</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ran unit tests, confirmed functional. Tweaked this to purposely break and confirmed they broke.</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>/trunk/main/bucket.c <span style="color: grey">(PRE-CREATION)</span></li>

 <li>/trunk/main/asterisk.c <span style="color: grey">(396929)</span></li>

 <li>/trunk/main/Makefile <span style="color: grey">(396929)</span></li>

 <li>/trunk/include/asterisk/config_options.h <span style="color: grey">(396929)</span></li>

 <li>/trunk/include/asterisk/bucket.h <span style="color: grey">(PRE-CREATION)</span></li>

 <li>/trunk/include/asterisk/autoconfig.h.in <span style="color: grey">(396929)</span></li>

 <li>/trunk/configure.ac <span style="color: grey">(396929)</span></li>

 <li>/trunk/configure <span style="color: grey">(UNKNOWN)</span></li>

 <li>/trunk/build_tools/menuselect-deps.in <span style="color: grey">(396929)</span></li>

 <li>/trunk/main/config_options.c <span style="color: grey">(396929)</span></li>

 <li>/trunk/main/sorcery.c <span style="color: grey">(396929)</span></li>

 <li>/trunk/makeopts.in <span style="color: grey">(396929)</span></li>

 <li>/trunk/tests/test_bucket.c <span style="color: grey">(PRE-CREATION)</span></li>

</ul>

<p><a href="https://reviewboard.asterisk.org/r/2715/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>