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

[Joshua Colp]

> On Aug. 1, 2013, 7:16 p.m., David Lee wrote:
> > Would buckets apply to something like the sound: resources, where a single sound may have multiple files on the filesystem (varying by language and format)?

A bucket is a container of files, what those files mean and how they may be related is up to the user.


> On Aug. 1, 2013, 7: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.

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.


> On Aug. 1, 2013, 7:16 p.m., David Lee wrote:
> > /trunk/include/asterisk/bucket.h, line 333
> > <https://reviewboard.asterisk.org/r/2715/diff/1/?file=43189#file43189line333>
> >
> >     Is there anything, other than metadata, that you can update about a bucket_file?

A scheme can update anything when it provides a bucket or file. An end user can only update metadata on a file, and the actual file itself.


> On Aug. 1, 2013, 7:16 p.m., David Lee wrote:
> > /trunk/main/bucket.c, lines 577-579
> > <https://reviewboard.asterisk.org/r/2715/diff/1/?file=43192#file43192line577>
> >
> >     Wouldn't this delete the file when the bucket_file object is cleaned up? That seems very unexpected.

I initially started this with the idea of a normal file, and a temporary file, as you saw from the function dec for it. As I implemented things it became rather difficult to "do the right thing" with it in regards to moving and copying. I would have had to add a new interface into the scheme to cover it. In the end I chose to simplify things by always having a temporary file which in the case of ODBC/IMAP/etc will actually be deleted. Other cases can create a symbolic link to act as a pointer to the real file and maintain the life cycle of that real file itself. I'm fine with changing it back though and trying to cover the cases if you feel that would be better though.


> On Aug. 1, 2013, 7: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'.

Sadly sorcery object IDs are of fixed length, and changing that would require another memory allocation which I'm meh over.


- Joshua


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


On July 30, 2013, 6: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, 6: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/862ebc89/attachment-0001.htm>