Hi Brian,
I find your approach quite elegant, but it requires clients to be able
to understand uri-templates, our I-D enables clients to navigate
hierarchies with requiring any knowledge of uri-templates. We wanted to
do the absolute minimum to enable hierarchies to be modeled and
therefore deliberately steered clear of any kind of 'search' functionality.
Brian Smith wrote:
[ I trimmed the CC's since everybody atom-protocol is probably subscribed to
atom-syntax too. ]
Nikunj Mehta wrote:
On Oct 31, 2008, at 9:37 PM, Brian Smith wrote:
What do you think about the search-based mechanism that I suggested
in the most recent "Hierarchical Collections" thread?
As an application developer, one has two choices in organizing items -
like del.icio.us (with annotations) or like Unix (with structure). The
approach you suggest in [1] sounds like the former. This approach
requires (many times the same) metadata to be provided in every entry
to identify its parent. However, that is not appropriate in all cases,
especially where hierarchy is required by the application.
I don't understand why the CMIS-ish approach would not be appropriate when
hierarchy is required, since it explicitly models hierarchy. What the use
cases that you had in mind?
The use cases we have given most consideration to are leveraging
Atom/AtomPub to provide a RESTful API for manipulating data in existing
enterprise applications.
Additionally, the approach requires a pretty big leap from current
standards to enable creation of child items since there is no means of
identifying a collection to post to for each entry.
If the application doesn't already have a specific collection in mind, it
can usually just use the collection associated with the feeds listing the
related entries (using the same atom:feed/app:collection discovery mechanism
that you suggest).
Moreover, the approach makes it a little cumbersome to add new
metadata to each link, since you are limited to primarily new
attributes. Of course, you can add elements to atom:link but then it
becomes hard to also add an inline version of the feed.
The search + link-based approach doesn't require nesting feeds within
entries or entries within entries. Instead, atom:link is used for
everything--just like the traditional relational model, the result set is
always flat, and hierarchies and relationships between the results are
reconstructed based the explicitly defined links within the results. As soon
as you nested entries and feeds within other entries, you run into troubles
when the nested entries are edited; in order for clients to see changes to
the nested entries you have to update the outer entry's
app:edited/ETag/Last-Modified, even if the outer entry was not modified.
That destroys the cachability of the collection and blows up the cost of
resyncing with the collection.
Just to be clear, we don't require nested feeds to be inlined, generally
I'd have a preference for keeping them out-of-line, but sometimes it can
be more intuitive to have the detail entries nested in-line with the
master entry.
Search can be added in an orthogonal way to the I-D and it can include
the closure capabilities you describe here. The I-D focuses on
achieving a hypertext-driven solution to hierarchy and avoids template
parsing and processing.
It seems to me that search is inevitable for all but the simplest AtomPub
servers. How searches are specified--with URI templates, HTML forms, XForms,
OpenSearch extensions, or something else--is up for debate. I chose URI
templates since most people here are familiar with them and since that it
what publically-available AtomPub(-ish) servers (like GData) are using. If
most servers are going to have a search interface, and that search interface
could be used to navigate hierarchies, then you don't really need a separate
mechanism specialized for navigating hierarchies.
I don't agree, for existing enterprise applications the number of
possible searches that the existing system can support is often very
limited, and those 'searches' are better expressed with concrete urls
rather than uri-templates.
The other thing I don't like about the hierarchical collections idea is that
it *requires* the server to implement a huge number of collections. Again,
that hurts the caching and the performance of collection syncing. And, that
is what creates the "what collection do I use" problem; if you only have one
collection for the application, you don't have to keep track of which one to
use. This simplicity also allows the client to resync with a large,
hierarchical collection with just a minimal number of requests.
And, at least as described in this draft, it results in entries that are not
self-describing. For example, using the draft's mechanism, given a link to
an entry, there is no way to find its master entry; you can only find the
link to the master from the detail feed that listed that entry. There is no
link from the entry to the detail feed either, so you have to remember what
feed(s) each entry was discovered from. That complicates the client-side
caching since you can't just reuse a normal HTTP cache. The search + link
approach allows the application to navigate up and down the hierarchy based
solely on the information encoded in each entry. At least in my experience
so far, a generic HTTP cache is highly effective with the search + link
model.
I'm not sure I follow this, can you provide an example where it would be
useful to discover the parent from the child, are you thinking something
like Atom Threading Extensions ? In particular I don't follow how this
complicates caching ?
Regards,
Colm
atom:link is powerful enough to model all relations, at least for read-
only purposes. This I-D is primarily extending Atom and AtomPub to
populate the hierarchical relations. It would be useful to see what
other read-write relations are of interest to this community.
OpenSocial's AtomPub-based protocol would be a good place to look for
examples.
One case so far where master/detail relationships have been important for my
application is where one entry's ACL has to be inherited by its child
objects. For example, think about a blog post. A blog post could have a lot
of images (media resources) embedded in it. But, you don't want the images
to be published until the entry has been published, and if you delete the
entry, you (usually) want the images to get deleted too. That means that
app:draft and any other kind of access control would be inherited by the
"detail" resources too. I'm sure a lot of uses of Atom outside of blog
publishing will have similar requirements for handling inherited traits.
Regards,
Brian
