[smila-dev] binstorage redesign

[Dmitry Hazin <dhazin@xxxxxxxxxxxx>]

There was a discussion started in email about binstorage redesign, I 
think it will be better if other developers can also take part in 
discussion. Here is the quotation from emails so far:

dhazin:
I think that for blackboard it will be the best to use the 3rd option 
from "Binary Storage – redesign proposal" section, so that blackboard 
will need to bind only one service and will know nothing about 
binstorage configuration and structure.

Regarding methods that should be exposed to blackboard:
a.void initialization() - new method

b.boolean deleteStorageFile(String key) - old method

c.InputStream getStorageFile(String path) - old method
I think it will be better to store and retrieve files by Id rather than 
by path, it will make binstorage API more clear and will remove 
dependency on filesystem metaphor (currently it is weird that blackboard 
has to create it's own 'path' for every attachment so this path can be 
used as Id, and save the only file with attachment to this path); it 
shouldn't matter for blackboard how files are physically stored, it just 
needs the ability to create/save/remove them.

d.createStorageFile(String path, String stream, byte[] content) - old method
Same as above, binstorage shouldn't expose anything filesystem-related, 
like path or stream parameters. The best will be just 
createStorageFile(String Id, byte[] content) method.

Additionally blackboard needs implementation for the File 
getPhysicalFile(StorageConfig config, String path) method that is 
currently in the StorageFile interface but not implemented yet. Probably 
some more methods will be required in the fututure.

Please keep binstorage API as simple for use as possible.


tmenzel:
the bin storage shall IMO mimic the file system as much as it makes 
sense. the only diff. is that it can be virtualized and spread physical 
storage over several machines but that should be hidden from the user 
and is only visible to the one setting the config! in that sense I'd 
very much stick to a path like structure.
but the current impl. is very strange in deed and I was quite confused 
by it as well. in particular, I remember, that a parameter was named (I 
think it was either path or filename) so badly that I thought of its 
usage and function completely wrong and it didn't make much sense to me 
after the explanation either. I think it was related to smth. that is 
theoretically possible but is not really used anywhere in any files 
system known to me....

anyhow, plz keep the bare logic simple and close to how one naturally 
deals with a FS. just using IDs/keys is the opposite of that.
if there is such a need for u, Dmitry, then I suggest we add another 
layer to handle this view.