RE: [smila-dev] binstorage redesign

[Thomas Menzel <tmenzel@xxxxxxx>]

what exactly do u see as "a problem of bin storage impl"?

deducting the folders from the string could be done but might not prove fine grained enough from the client view in some cases. otherwise u could also argue that for the java.io API...

besides it would also requite for externally defined conventions such as used path delimiters / or \ etc which is not good OOP design.

as I said: we can provide 2 interfaces, a flat and a tree-style and then the client can decide which he wants to use.

Kind regards
Thomas Menzel @ brox IT-Solutions GmbH


-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Ivan Churkin
Sent: Dienstag, 30. September 2008 09:49
To: Smila project developer mailing list
Subject: Re: [smila-dev] binstorage redesign

Imho, its a problems of bin storage implementation, it should not be 
reflected in API

For my interface sample

interface BinStorage{
    InputStream get(String id);
    String add(InputStream stream);
    update(String id, InputStream stream);
    remove(String id);
    boolean exist(String id);
}

this specific binstorage implementation may generate String Id in Path 
style during add()

--
Ivan



Thomas Menzel wrote:
> well, my thinking is that we provide a virtual file system as a binary storage. 
>
> hence a client (not now, but it is thought of that the bin storage is an infrastructure item that may offer his service to other clients as well) may want/need to organize his data hierarchically, as if in normal file system.
>
> if that is not needed for now in BS then we can limit the impl. currently to just offer a hashset-style storage but the API should support hierarchical (ie tree) structures and an FS is the most natural IMO.
>
> we may also name the child just flat bin storage and later do a hierarchical bin storage if u like that better.
>
> there is also most likely a performance aspect to full flat vs. hierarchical, as the lookup will be faster in a tree structure. that is not noticeable now with few items but when u have millions it will. 
> also: when distributing the data in a cluster, nodes in a tree are a very welcome entity that can be mapped directly a hardware nodes.
>
> all these are details for the (near) future but need to taken into consideration.
>
> Kind regards
> Thomas Menzel @ brox IT-Solutions GmbH
>
>
> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Ivan Churkin
> Sent: Dienstag, 30. September 2008 09:04
> To: Smila project developer mailing list
> Subject: Re: [smila-dev] binstorage redesign
>
> I completely agree with.
> Imho, binstorage API should be very simple. I can imagine that some 
> customer will want to use database for storing binary data.
> As I understand there is only one problem - some text miner engine have 
> to get real file access to extract data.
>
> --
> Ivan
>
>
>
> Dmitry Hazin wrote:
>   
>> Why do you think that that binstorage should mimic the file system? 
>> What is the reason for that? The simplest will be just manage files in 
>> binstorage by Id (ie by name), and binstorage should decide how to 
>> store files physically, in file system or using any other way. So I 
>> don't see any the reason why binstorage should mimic filesystem, 
>> please explain your point.
>> _______________________________________________
>> smila-dev mailing list
>> smila-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/smila-dev
>>     
>
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev
>   

_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev