Luke Arno wrote:
If we really need them then maybe we need a box.
I don't think we need any directives, atm.
The challenge with this statement is that existing implementations are
already using these kinds of directives.
Ouch. Invoking the Ant boogie man is dirty pool :)
I would guess that all but the simplest 20 percent of
distributed applications built on APP will need such a
box so it makes a very good extension.
If all but the simplest 20 percent need it, then it's also a good
candidate for an optional core element as well.
I think most implementations will just be pushing entries
around. Blogs, wikis content management...
Systems that do more (ecommerce transactions or what
have you) over the APP will need to decide on appropriate
protocols.
I am *all for* putting language in an implementers guide
that encourages implementations with extensive
processing models to use some kind of box.
The challenge with this is that our most common use cases (blogs, wikis,
content management) aren't just pushing entries around; they have an
already demonstrated need for this control stuff and are already
starting to dump it into atom:entry (have been for some time now). The
argument about pub:control is: given that we know that controls elements
will and are already being stuffed into atom:entries, does it do any
good to provide a standard container for those to go into (regardless of
whether that container is pub:control or atom:entry). In so doing, do
we help ward off any Bad JuJu Spirits implementors will face in the
future. If we don't provide a container and just let extensions figure
it all out as they go, are we going to cause any significant problems
down the road? Telling folks to put their stuff in a box doesn't seem
to help if everyone puts their own stuff into their own individual boxes.
We're not inventing anything new here. We're just trying to figure out
if we should standardize what our most common existing implementations
are already doing or recommend a better way of doing it.
- James
