I'll try to do more snipping on these long threads. I tend to be a little over cautious about taking things out of context.
Also Gmail is spoiling me :) - Luke ---------- Forwarded message ---------- From: Luke Arno <[EMAIL PROTECTED]> Date: Oct 29, 2005 1:57 PM Subject: Re: Regarding PaceDropControl To: Bill de hÓra <[EMAIL PROTECTED]> Cc: atom-protocol <[EMAIL PROTECTED]> On 10/29/05, Bill de hÓra <[EMAIL PROTECTED]> wrote: [ snip ] > That's because you have one PI. Now add 10 more PIs; that's 10 more if > statements, or 10 more XPaths, or .... The minute I want to stage > processing so I do all the directive stuff in one go/thread/cpu/handler > I have a mess of if statements instead of nicely decoupled code. It's > bad enough that to uniformly process regular atom, now I will have to > add a skip check on pub:control, but mixing the two together is random > (pun intended). > If your distributed application, being built *on top* of APP has a vocabulary of 10 PIs then by all means, put them in a box. Some extension for this is a great idea. > Not being able to glob protocol directives is a spec bug. It's like > allowing the HTTP entity to appear anywhere between the headers. Or > having some APP stuff in headers and some in entries. Or putting entry > metadata inside content (hello microformats!). > I don't disagree with your points (except your characterization of microformats but this is not the list for that). I think we are just looking at the APP as having different goals. You call them "protocol directives". What protocol? What directives of APP need to go in a box? I guess the disconnect in our mental models here is this: APP as just a publishing protocol or APP as distributed applications protocol. I think APP will be an even better substrate for application protocols to build on to if we stay out of their processing models and sticks to the humble task of pushing entries around. - Luke
