Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [smila-dev] BinaryStorage service concept

Hi,

there are at least two more people who think that using "record" and 
"attachment" in the BinStorage API names is not appropriate, see the 
"Discussion" page of the requirements page [1], so now there are three 
(at least ;-). 

Maybe Igor can say if these names really are a hard part of the requirements?

Yours, 
Juergen.

[1] http://wiki.eclipse.org/Talk:SMILA/Component_Requirements/Record_Binary_Storage_Requirements


> -----Original Message-----
> From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Marius Cimpean
> Sent: Monday, October 20, 2008 1:33 PM
> To: Smila project developer mailing list
> Subject: Re: [smila-dev] BinaryStorage service concept
> 
> Hi Dmitry
> 
> the API re-naming is based on the Binarystorage requirements :
> http://wiki.eclipse.org/SMILA/Component_Requirements/Record_Binary_Stor
> age_Requirements
> 
> 
> Best Regards,
> Marius
> 
> ----- Original Message -----
> From: "Dmitry Hazin" <dhazin@xxxxxxxxxxxx>
> To: "Smila project developer mailing list" <smila-dev@xxxxxxxxxxx>
> Sent: Monday, October 20, 2008 2:23 PM
> Subject: Re: [smila-dev] BinaryStorage service concept
> 
> 
> Minor note regarding Binary Storage Service API: should it expose
> knowledge about Records and Attachments?
> Probably it's worth to use just something generic like getObject,
> saveObject etc?
> 
> Thanks,
> Dmitry
> 
> Marius Cimpean wrote:
> > Hi all,
> >
> > The Binary storage concept page is available -  please have a look
> and
> > submit your remarks. We can discuss the binary storage based on this
> page
> >
> > http://wiki.eclipse.org/SMILA/Project_Concepts/Binary_Storage
> >
> > Best Regards,
> > Marius
> >
> >
> > ----- Original Message ----- From: "Thomas Menzel" <tmenzel@xxxxxxx>
> > To: "Smila project developer mailing list" <smila-dev@xxxxxxxxxxx>
> > Sent: Monday, October 13, 2008 1:16 PM
> > Subject: RE: [smila-dev] Re: Problems with BinStorage
> >
> >
> > hi jürgen,
> >
> > very nice, if u had not written this, i would have. thx
> >
> > from what I understood, VFS supports already diff. storage
> implementations
> > for diff. *mountpoints*. so, with VFS it's already possible to have a
> DB,
> > distributed FS, local FS at the same time, albeit in diff.
> namespaces.
> >
> > and yes, I think it is not part of the client to say directly, I want
> DB
> > storage or local, it just would have to know the NS it is config'ed
> for
> > and hence all this moves into the config/admin realm. he then has to
> > decide what is best in what situation.
> >
> > also: having followed the discussion so far, I think it is OK to say
> that
> > at this time it makes more sense to write the BinStorage API such
> that it
> > fits for the current use case, which is that the client doesn't need
> > control of folders (or am I wrong here?).
> >
> > an interface for FS-like distributed storage we can add later IMO.
> and I
> > also have come to think that this could actually go into a new API
> that is
> > different or just complementary to the BinStorage API.
> >
> > Kind regards
> > Thomas Menzel @ brox IT-Solutions GmbH
> >
> >
> > PS: should we open a bug for this discussion as well? or do u prefer
> > keeping this on the dev list?
> >
> > -----Original Message-----
> > From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-
> bounces@xxxxxxxxxxx]
> > On Behalf Of Juergen.Schumacher@xxxxxxxxxxx
> > Sent: Montag, 13. Oktober 2008 12:02
> > To: smila-dev@xxxxxxxxxxx
> > Subject: RE: [smila-dev] Re: Problems with BinStorage
> >
> > Hi,
> >
> > It's not really clear to me, what this discussion is about currently
> (API?
> > backend?), so I'll try to sum up my point of view on the complete
> package,
> > and hopefully we'll get some answers from it (-;
> >
> > The purpose of BinStorage is to store millions (or billions) of
> (possibly
> > large) binary objects and make them available to a relatively large
> number
> > of record processors running distributed in a "cluster" of computers.
> > Currently I do not know what kind of backend might be the best to
> match
> > these requirements, I rather think that it should be exchangeable in
> order
> > to be able to match different requirements: In one application it
> could be
> > simply a shared file system, because performance is sufficient and
> > administration is easy, in other applications distributed file
> systems
> > might be necessary, or some database technology or whatever. I don't
> think
> > that we can decide this now for good. Thus the API must be as generic
> as
> > possible to be implementable on any kind of backend.
> > And the details of the storage backend must not be of relevance to a
> > client: One blackboard just writes the attachments of a record to bin
> > storage, another one retrieves it again. They should not have to care
> > about where to put the objects in a hierarchy for good performance,
> it's
> > the task of BinStorage to create such hierarchies internally if a
> flat
> > storage is not sufficient.
> >
> > On the other side, I'm not against having a BinStorage API that
> enables
> > different kinds of clients to use different "namespaces" in
> BinStorage to
> > separate their data. These namespaces could be hierarchical: a "file
> > system" metaphor behind the API might be helpful for developers using
> > BinStorage, because most users are accustomed to it, even if the
> actual
> > storage has nothing to with a file system.  On the other hand this
> might
> > enable the configurator/administrator of BinStorage to distribute
> > partitions of data to different storage mediums (just dreaming now ;-
> ) for
> > better performance. But BinStorage must not rely only on structures
> > provided by the clients, but must organize the stored data for
> optimal
> > performance even if a client does not provide any structure at all.
> >
> > Hopefully this has not increased the confusion even more (-;
> >
> > Yours,
> > Juergen.
> > _______________________________________________
> > 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
> 
> 
> 
> _______________________________________________
> smila-dev mailing list
> smila-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/smila-dev


Back to the top