On 10/29/05, James M Snell <[EMAIL PROTECTED]> wrote: > Luke Arno wrote: > >On 10/29/05, James M Snell <[EMAIL PROTECTED]> wrote:
[ snip ] > >distributed-applicationy > > > Is that the technical term ;-) > You know it is. :) > >How many processing instructions is the average > >implementation using in an atom entry? > >(approximately) > > > >What are they? > > [ snip ] [ James listed the stuff I summarize below here. ] Cool. Thanks, James. I would not have thought of some of these. A few of these seem lame to be but that is neither here nor there. draft significant comment on/off trackbacks on/off pluggin X on/off accepted encodings "purty" quotes linebreak conversion URL slugs (had those in my garden once) ping/trackback URL date to publish tidy me wikitext (ResT or whatever) ... Some tell clients what to do. Some tell consumers what to do. Some tell the server what to do (and probably at different points in handling the entry - on the way in/out). Some will get stripped but at different times. I don't see a uniform model. I don't see a big call for ordering. I don't see that putting these in a box gets us much of anything at all. [ snip ] > >What constitutes a sufficiently extensive processing > >model to call for a box? 3 instructions? 5? ... > > > Counting the number of directives is the wrong approach. Base the > decision on the amount of need. If our primary use cases are going to > require a way of expressing these directives (which they do) then we > really should figure out a standard way for them to do it (at least in > my opinion). > But how do we measure needful? Implementers need to be able to express whatever PIs they want (good or bad - it is up to them). Maybe I don't follow. I brought up number, as Bill did, as an indicator of complexity. Reflecting on the specifics of what is being done, I am not even sure that complexity is the question, though. The question is "what is the model?" and I don't think we have any one clear model. I don't think we should. In other words, the question is: what is consistent such that we *can* standardize it in a meaningful way? At this point I think control is a meaningless security blanket that makes us feel that we have somehow put the chaos of unpredictable processing models into a cage. I have written the following before but is has a new dimension: <quote-myself> And implementations will want to handle extensions (processing or otherwise) in different ways. 1. The implementation knows what it is and handles it according to its rules. 2. The implementation knows about some flag and handles it according to rules for that flag. 3. The implementation knows about some box and handles it according to its rules for that container. 4. The implementation does not know what it is but sends it on through. 5. The implementation does not know what it is and strips it. etc. </quote-myself> The extra dimension is time. These are options for how extensions will be handled at various points in clients and servers. We can say that we have made some universal box and feel that we have somehow turned this chaos into order but we have not. All we have done is add a box. Even beyond that our box will no doubt leak. People are going to define extensions (processing and otherwise) as attributes on link elements or anything else. There is nothing we can do to tame this chaos. When I started this thread I thought that I was going after a do-nothing that is cluttering up APP but now I think it is worse: pub:control is nothing but a false sense of security. If it did anything it would be even worse than that. We cannot and should not know what the next protocol up the stack will look like. - Luke
