Morning Gary, On Tue, May 12, 2009 at 10:24 AM, Gary Mazz <garymazzaferro@gmail.com>wrote:
I like Tim's explanation.
I have some on some trivial subjects...
1) Are we also talking about using IRIs or URIs only ?
There was some discussion about this before with Ben Black - Atom IDs are not meant to be dereferenceable so for simplicity (especially w.r.t. concurrency and migration/merging of resources safely) there was an earlier decision to use version 4 (random) UUID URN<http://en.wikipedia.org/wiki/Uniform_Resource_Name>s for the IDs. There was then some contention as to whether link relations should specify the URN of the target resource or a dereferenceable URI... I prefer the former (bearing in mind that the same resource can appear at multiple endpoints, dereferenceable URIs are easily created and working internal document references are useful) while Ben prefers the latter. These and related topics probably need further discussion re: pros and cons down the road.
2) What is the thoughts on handling foreign markups at endpoints and gateways/bridges ?
Foreign markups should/must not be touched (not sure which requirement level to use here) as this is the basis of much of our extensibility.
3) How are the scheme attributes handled for child element when presented without the parent element that has the scheme assignment ?
Elaborate - not sure what you mean here.
4) Can we publish work spaces ? Will work spaces require authorization?
Workspaces are neither required nor supported by Google's GData implementation so there is good reason to believe that we won't need them. If the use case doesn't exist then I'd opt for the simplicity of excluding them from the spec.
5) Will there be top level resources be defined? or will each vendor define their own resources schemes? How do we preserve proprietary technology?
We need to define this, at least at a high level, for interoperability. So far I had made provision for three top level categories (compute, storage and network) or "types" (what Google call "kinds").
6) How are document writers/editors defined and authorized ?
Out of scope - I'm not even sure we need to specify how they are authenticated (though I have a whitelist on the Resources page already if we take an interest in this). Authorisation can range from none (simple XML file on embedded web server) to fine grained/field level, depending on the implementation. I'm expecting this to be an area where implementors can differentiate themselves.
7) Will there be document caching/synchronization policies and schemes ?
Google have used ETags with good results<http://globelogger.com/2008/11/gdata-now-compliant-with-atompub.html>, and this makes a lot of sense given much of the work for clients will be keeping their view of the world in sync with reality. Being able to crank up a desktop client and have it display a large number of [cached] resources in seconds even over a modest link becomes a reality with this approach - and web based third-party services like RightScale have similar needs.
8) How are collection components authorized ? Private/authorized partial lists in collection of public lists ?
See above - two different users looking at the same endpoint may or may not see different things depending on which resources they are authorised to see. Public cloud offerings may have many millions of resources at a single endpoint but your average user will only see a small handful, while an enterprise setup may have all authenticated users seeing the same thing. I don't see much point in trying to burn any of this into the standard.
9) What are the policies for conformance levels? Will occi define our own ?
Possibly, though I would prefer to keep the core simple and require everyone to implement it fully and faithfully.
10) What will the policy be for non-IANA content ?
I'm guessing by this you mean Internet media types<http://en.wikipedia.org/wiki/Internet_media_type>that are not defined by IANA, in which case we have the usual x-, vnd. and prs. namespaces available.
Sorry for the long list..
No problem - the more detailed the discussion the better the result. Sam
Tim Bray wrote:
On May 11, 2009, at 1:54 PM, Sam Johnston wrote:
The ideal core protocol would contain no references to infrastructure, rather allow manipulation of resources (CRUD, linking, actuators) irrespective of what the resource was. It would thus be reusable for any resource (as Google have done for 16 different services and who knows how many different resource types already with GData).
Odd though it may seem, until I saw this I didn't grok what Sam was proposing. Maybe I still don't, but let me take a guess:
You're focusing not so much Atom the RFC4287 data format, but AtomPub the RFC5023 publishing protocol as implemented notably in GData and lots of other places, and do generic Web-resource CRUD where the resources happen to represent cloud infrastructure objects. Thus you outsource most of the work of CRUD specification. Then, you layer cloud-specific stuff on top of that. Then collections of servers and clusters and networks and so on are perforce represented as Atom Feeds.
Is that the essence of it? -Tim _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg