[asterisk-dev] [Code Review] 2715: Bucket: A generic file and directory API

[David Lee]

> On Aug. 1, 2013, 2:16 p.m., David Lee wrote:
> > /trunk/tests/test_bucket.c, lines 211-215
> > <https://reviewboard.asterisk.org/r/2715/diff/1/?file=43194#file43194line211>
> >
> >     I think Mark's already hammered on this, but I would expect the id of a bucket to be its URI. It does stand for 'uniform resource identifier'.
> 
> Joshua Colp wrote:
>     Sadly sorcery object IDs are of fixed length, and changing that would require another memory allocation which I'm meh over.

And if the URI is mary://poppins/supercalifragilisticexpialidocious-is-something-quite-atrocious?

If I'm looking at the right code for the id, then the id should actually be a generated UUID. Maybe you should use a version-5 UUID, so you get a consistent id for URI's with low probability of collision. Unfortunately, I don't think libuuid will help us out with that, so you'll have to look into section 4.3 or RFC 4122. Looks like it's just SHA-1 and a series of convoluted memcpys.


> On Aug. 1, 2013, 2:16 p.m., David Lee wrote:
> > /trunk/include/asterisk/bucket.h, lines 314-323
> > <https://reviewboard.asterisk.org/r/2715/diff/1/?file=43189#file43189line314>
> >
> >     This is a bit weird. Normally, rename(2) is an atomic operation, and lots of interesting things require it to be atomic.
> >     
> >     I don't know if those interesting things are relevant to how one would use buckets, but it's worth thinking about from an API perspective.
> 
> Joshua Colp wrote:
>     So - as it is written you can move files between different schemes. Have a local file? Move it to ODBC, if you want. Doing that atomically is impossible since you've got two schemes and backend storage mechanisms in play.

Make sense. Feel free to drop the issue.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2715/#review9292
-----------------------------------------------------------


On July 30, 2013, 1:39 p.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2715/
> -----------------------------------------------------------
> 
> (Updated July 30, 2013, 1:39 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> 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 "bucket" 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
> 
> 
> Diffs
> -----
> 
>   /trunk/include/asterisk/bucket.h PRE-CREATION 
>   /trunk/include/asterisk/config_options.h 395727 
>   /trunk/main/asterisk.c 395727 
>   /trunk/main/bucket.c PRE-CREATION 
>   /trunk/main/config_options.c 395727 
>   /trunk/tests/test_bucket.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2715/diff/
> 
> 
> Testing
> -------
> 
> Ran unit tests, confirmed functional. Tweaked this to purposely break and confirmed they broke.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130801/ad88d8f9/attachment.htm>