[openbiblio-dev] bibserver dao

Wed Aug 24 20:35:42 UTC 2011

On 24 August 2011 21:28, Jim Pitman <pitman at stat.berkeley.edu> wrote:
> Rufus Pollock <rufus.pollock at okfn.org> wrote:
>
>> We also had a chance to talk about this. From my end the issue is that
>> file storage always introduces complexity both in code and more widely
>> (e.g. easy to have security holes and allow attackers to write over
>> your bashrc or similar ...) and we don't have any immediate need for
>> it. I'd therefore suggest leaving it out until we have a clear and
>> present need (moreover at that point, the need e.g. asynchronous
>> processing, might influence the implementation).
>
> But BibJSON derived from the file  upload is still being cached in the database, right?

Yes. We definitely store it in the database :-)

> That should be enough for a first pass. I think at least initially users should be expected
> to maintain their own files and BibServer provides a read-only service with its own internal
> caching of data from upload. There will still be the issue of how to remove data that has been uploaded
> e.g. in error. How exactly does the user authenticate to show they were the owner or the file with right
> to remove it?

Which is why you'll almost certainly need some kind of web user
interface for editing / deleting etc (even if just used by sysadmins).

> This sort of thing, and naming of files,  is what makes file upload much more difficult than pulling data from urls.
> Then, whatever is at the end of the url is the source, and it is harmless if anyone in the world presses a refresh button.
> If the url returns an error, the local store should not be overwritten. This should happen only of something that looks
> like bib data has been acquired.

Right. agreed that pulling from urls is the main priority though you
will still need to do things like delete a collection taht was
accidentally imported for example.

rufus