This post is more than 5 years old
6 Posts
0
1148
Discussion: Make sense to change all the code from the XAM API to Centera SDK?
1) Make sense to change all my code from the XAM to SDK?
2) EMC will still invest in the Centera SDK and the Centera by itself?
3) The same SDK will still be used to access the ATMOS?
Let's Discuss.
mckeown_paul
409 Posts
1
December 12th, 2012 05:00
There is a p6 planned for XAM in the near future which will include the leap year patch (officially). If any needs the leap year patch please email me requesting it.
Future revisions of Centrastar will address the XAM mutable metadata issue. This is not really the forum for posting information on future releases of C*, ifyou wish more details and you are a) a customer please contact your sales account team or b) an ISV please email me.
We are currently documenting what is required to "port" from XAM to the Centera API. Be aware that currently a Centera API based application cannot open XAM Xsets even if you could derive the ultimate CA that the XAM Xset has. The Xset is based on CDF(s) and blobs just like the Centera API but the CDF(s) in this case have a special format
nostack
6 Posts
1
November 16th, 2012 15:00
Excellent thoughts Mike.
My big fear is exactly this, I'm using many features only available (or facilitated) by the XAM and a hugh work to change to something that will not evolute and is going to be changed.
Thanks.
Please, if someone has an different idea or just agree, please comment.
mfh2
208 Posts
1
November 16th, 2012 15:00
Hello nostack -
Good topic. My thoughts:
1) It's worth trying to switch back, although the XAM kit still works and the current code will be supported for as long as the current generations of OSs are still supported. It may be difficult to switch back, especially if you are taking advantage of XAM's big differentiator: non-binding metadata. There is no interface in the Centera SDK to implement this; all metadata is treated as 'binding'. Emulating this feature with the Centera SDK is possible, but it's tricky and probably not a good idea (depending on the typical rate of change for your application's metadata).
2) I can't speak to EMC's plans but the Centera product manager has stated publicly (in a webcast June 2012) that EMC is not planning to sunset the Centera API interface although the future Centera hardware may be different than what we have today. Jason, if that has changed, this woudl be a good place to let us know.
3) Yes, the same Centera SDK can access the Atmos through the Atmos-CAS layer. However, the Atmos does not support retention features so it will act as a 'basic' mode Centera. If you need hardware retention support for your API client the Centera hardware is the only choice today.
Best Regards,
Mike Horgan
www.interlock-tech.com
twinkeloogje
10 Posts
1
November 20th, 2012 13:00
Same kind of problem for us ...
we have 75 million objects stored in XAM, we don't use retentions yet, but we have a 3rd party application for which we don't know if they depend on non-binding data ? ...
On top of this EMC promises to deliver new releases on a breaking fix basis ... we already know about 2 of them ... one of them for more then 2 years now ... when will EMC fulfill this promise ?
1) we had a bug on February 29th (leap day) - with a hot fix the same day, but not a full release.
2) it is known for years now (and documented in the release notes) that when a XAM object is deleted, that the clips which contain non-binding data are left orphaned on the Centera ... is this fixed in a recent release of the Garbage Collector ?
What support will EMC give to return to the SDK ? Is there an easy way to obtain/convert clipids from the XAM UIDS ?