[
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