Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:SMILA/Component Requirements/Record Binary Storage Requirements"

Line 1: Line 1:
i'd wouldnt use the smila specific 'record' and 'attachment' name parts as all in/out arguments are generic.
+
[[User:T.menzel.brox.de|Tom]]: I wouldnt use the smila specific 'record' and 'attachment' name parts because in/out arguments are generic.
  
[[User:Juergen.schumacher.empolis.com|Juergen.schumacher.empolis.com]] Yes, indeed. There is nothing record-specific in the arguments so we do not need to talk about records and attachments. But I wonder if it would make sense to add another parameter to be able to ensure that different clients that use BinStorage for difference purposes do not have ID collisions. Otherwise one client woudl overwrite the BLOB of another client by accidently using the same ID. So we could have:
+
[[User:Juergen.schumacher.empolis.com|Juergen.schumacher.empolis.com]] Yes, indeed. There is nothing record-specific in the arguments so we do not need to talk about records and attachments. But I wonder if it would make sense to add another parameter to be able to ensure that different clients that use BinStorage for difference purposes do not have ID collisions. Otherwise one client would overwrite the BLOB of another client by accidentally using the same ID. So we could have:
  
 
<source lang="java">
 
<source lang="java">
Line 13: Line 13:
  
 
Alternatively we could require that IDs are not unstructured strings but something like "URIs" (maybe even javax.xml.namespace.QName instead of java.lang.String?)
 
Alternatively we could require that IDs are not unstructured strings but something like "URIs" (maybe even javax.xml.namespace.QName instead of java.lang.String?)
 +
 +
[[User:T.menzel.brox.de|Tom]]: ID wouldnt do that! Reason: how the ID is generated is a matter of config and hence the admin is in charge to ensure that IDs include all needed data so nothing gets overwritten accidentally. if he wants to be sure then he may use the namespace to achieve separation.

Revision as of 09:24, 15 October 2008

Tom: I wouldnt use the smila specific 'record' and 'attachment' name parts because in/out arguments are generic.

Juergen.schumacher.empolis.com Yes, indeed. There is nothing record-specific in the arguments so we do not need to talk about records and attachments. But I wonder if it would make sense to add another parameter to be able to ensure that different clients that use BinStorage for difference purposes do not have ID collisions. Otherwise one client would overwrite the BLOB of another client by accidentally using the same ID. So we could have:

void store(String namespace, String id, InputStream stream);
void store(String namespace, String id, byte[] blob)
byte[] fetchAsByte(String namespace, String id)
InputStream fetchAsStream(String namespace, String id)
void remove(String namespace, String id)
int fetchSize(String namespace, String id)

Alternatively we could require that IDs are not unstructured strings but something like "URIs" (maybe even javax.xml.namespace.QName instead of java.lang.String?)

Tom: ID wouldnt do that! Reason: how the ID is generated is a matter of config and hence the admin is in charge to ensure that IDs include all needed data so nothing gets overwritten accidentally. if he wants to be sure then he may use the namespace to achieve separation.

Back to the top