On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote:
>
> Eric Scheid wrote:
>
> >On 28/10/05 8:30 AM, "Luke Arno" <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>As I am proposing this, Sam would expose a feed
> >>with published dates using the APP mime type for
> >>republishing purposes.
> >>
> >>
> >
> >that's assuming he *has* published dates in the first place.
> >
> >
> >
> No need to assume anything.  According to his own source code, he does not.
>
> http://www.intertwingly.net/code/mombo/entry.py
> http://intertwingly.net/stories/2005/09/21/rails.tgz
> http://intertwingly.net/atom.tgz
>

Published...

So I have read and thought some more about this,
and I am within a hair's breadth of being convinced.
I don't love it. I don't like it. But it may be pragmatic.

I do see this in PaceDatePublished under Impacts:
"Publishers will need to provide an additional date."
It seems then that at one time the idea of requiring
implementers to have a published date was at
least considered.

I don't want to create barriers to adoption but we
have chosen to use HTTP methods that required
some pushing for support...

Baaahh!

Maybe we can at least say in an implementers
guide that published should be treated as published
and perhaps a future version of APP can do the
right thing.

It occurs to me that in most mail clients, drafts are
just kept in a folder. Why not just have draft
collections? Have we talked about this before?

This was my "beginner's mind", my first instinct of
how to approach the drafts problem.

I am still firmly opposed to pub:control and doubly
opposed to pub:significant.

- Luke

Reply via email to