I suggest to start by limiting to discussion to any attribute stored with the 'data' (i.e. not every attribute traveling with the data to/from and between servers) ..
E.g. Consider X-Delete-At while not considering X-Delete-After (as it is never stored with the data)
Another somewhat non-orthodox classification is between USER and SWIFT as the entity creating the metadata:
- If the system is ok with the user generating the information (and even if it is in practice being also generated in some cases by a middleware) the attribute would be considered as a USER MD (E.g. we have a middleware that will set X-Container-Sync-To but we will still consider it to be a USER MD.
- If the system is enforcing the information (and even if it tested against some user provided information) we will consider it as a SWIFT MD. E.g. ETag is enforced by Swift, yet the user may send his own version which will be tested against the system version.
Objects Metadata:
I suggest to start by limiting to discussion to any attribute stored with the 'data' (i.e. not every attribute traveling with the data to/from and between servers) .
E.g. Consider X-Delete-At while not considering X-Delete-After (as it is never stored with the data). I guess a very similar analysis can be made on the incoming/outgoing headers – which may make sense also, but we need to start somewhere…
Another somewhat non-orthodox classification is between USER and SWIFT as the entity creating the metadata:
- If the system is ok with the user generating the information (and even if it is in practice being also generated in some cases by a middleware) the attribute would be considered as a USER MD (E.g. We have a middleware that will set X-Container-Sync-To but we will still consider it to be a USER MD.
- If the system is enforcing the information (and even if it tested against some user provided information) we will consider it as a SWIFT MD. E.g. ETag is enforced by Swift, yet the user may send his own version which will be tested against the system version.
Coming from this, here is a first version of suggested classification in Swift:
Generated by the User Generated by Swift Can be read Hidden Can be read Hidden
Modulates Swift Control MD <<Never>> Swift MD Internal MD
Does not modulate Swift User MD <<Never>> Swift MD <<Never>>
Or in other words:
- Control MD is any MD that controls/modulates swift (and can be read and written by the user)
- User MD is any MD that the user stores in Swift and Swift and does not controls/modulates swift
- Swift MD is MD generated by Swift that the user can read and may also control/modulate swift
- Internal MD is MD generated by Swift, hidden from the user (i.e. used internally)
I suggest to start by limiting to discussion to any attribute stored with the 'data' (i.e. not every attribute traveling with the data to/from and between servers) ..
E.g. Consider X-Delete-At while not considering X-Delete-After (as it is never stored with the data)
Another somewhat non-orthodox classification is between USER and SWIFT as the entity creating the metadata:
- If the system is ok with the user generating the information (and even if it is in practice being also generated in some cases by a middleware) the attribute would be considered as a USER MD (E.g. we have a middleware that will set X-Container-Sync-To but we will still consider it to be a USER MD.
- If the system is enforcing the information (and even if it tested against some user provided information) we will consider it as a SWIFT MD. E.g. ETag is enforced by Swift, yet the user may send his own version which will be tested against the system version.
Objects Metadata:
I suggest to start by limiting to discussion to any attribute stored with the 'data' (i.e. not every attribute traveling with the data to/from and between servers) .
E.g. Consider X-Delete-At while not considering X-Delete-After (as it is never stored with the data). I guess a very similar analysis can be made on the incoming/outgoing headers – which may make sense also, but we need to start somewhere…
Another somewhat non-orthodox classification is between USER and SWIFT as the entity creating the metadata:
- If the system is ok with the user generating the information (and even if it is in practice being also generated in some cases by a middleware) the attribute would be considered as a USER MD (E.g. We have a middleware that will set X-Container-Sync-To but we will still consider it to be a USER MD.
- If the system is enforcing the information (and even if it tested against some user provided information) we will consider it as a SWIFT MD. E.g. ETag is enforced by Swift, yet the user may send his own version which will be tested against the system version.
I created a google docs page to summarize the different Metadata attributes I have found so far. /docs.google. com/spreadsheet /ccc?key= 0Anreg7c52mt0dG JUb2xyWHltMWdxa lE3cEF6azFrRGc# gid=0
See: https:/
whoch should be open for everyone to read (anyone interested in editing at the source, please send me your gmail).
Coming from this, here is a first version of suggested classification in Swift:
Modulates Swift Control MD <<Never>> Swift MD Internal MD
Does not modulate Swift User MD <<Never>> Swift MD <<Never>>
Or in other words:
- Control MD is any MD that controls/modulates swift (and can be read and written by the user)
- User MD is any MD that the user stores in Swift and Swift and does not controls/modulates swift
- Swift MD is MD generated by Swift that the user can read and may also control/modulate swift
- Internal MD is MD generated by Swift, hidden from the user (i.e. used internally)