Timestamps
Scott Merrill
We currently store two different time formats in the post table:
pubdate is a DATETIME
updated is a TIMESTAMP
According to some documentation I've read, TIMESTAMPs have an upper
bound in the year 2037.
I propose that we standardize on DATETIME for all time values to be
stored in the DB. Your thoughts?
ITEM TWO
The Atom Syndication format suggests that we return entries sorted by
the updated time. We currently set the "updated" value in the DB for
an edit, no matter how small. This means that fixing a typo in a post
from two years ago will send that post to the top of your Atom feed.
The Atom Publishing standard suggests that when fetching a list of
entries, they be sorted by their edited value, where "edited" means
"any edit, regardless how substantial".
Geoffrey Snedders has suggested that we add a third timestamp column
to the post table to hold the value of the last minor edit. This
field, "edited", would be updated any time a post is edited, for any
reason.
The "updated" column in the DB would be used to store the time of that
last major edit.
The "pubdate" column would store the original publication date.
In order to effect this change, in addition to the new column, we
would need UI on the post composition screen allowing an author to
indicate whether an edit is minor or not. I suggest a single
checkbox, labeled "This is a minor edit" that is checked by default.
I believe it to be the case that most people will correct typos more
often than they make a major change to a post.
What do folks think about extending the schema to include a new "edited" column?
What do folks think about adding a checkbox to the post composition screen?
Rich Bowen
ITEM ONE
We currently store two different time formats in the post table:
pubdate is a DATETIME
updated is a TIMESTAMP
According to some documentation I've read, TIMESTAMPs have an upper
bound in the year 2037.
I propose that we standardize on DATETIME for all time values to be
stored in the DB. Your thoughts?
Michael C. Harris
> What do folks think about extending the schema to include a new "edited" column?
> What do folks think about adding a checkbox to the post composition screen?
+1.
This is one of the items from my AtomPub post last October, where I
described the issue, the solution, and provided references.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Andy C
fix malformed tags in multiple posts after migration from WP.
Consequently, my handful of RSS readers were inundated with duplicated
posts from yesteryear.
However, while the proposed change would have enabled me to avoid
this, I've go to say that most of my minor, typo correcting edits are
relatively infrequent.
I think these additional check-boxes would just be irritating noise on
the 'blank canvas; of the article editor.
On Feb 15, 10:21 pm, "Michael C. Harris" <michael.twof...@gmail.com>
wrote:
> > What do folks think about extending the schema to include a new "edited" column?
> > What do folks think about adding a checkbox to the post composition screen?
>
> +1.
>
> This is one of the items from my AtomPub post last October, where I
> described the issue, the solution, and provided references.
>
Michael C. Harris
>
> Coincidentally, I have been (badly) bitten by this issue as I had to
> fix malformed tags in multiple posts after migration from WP.
>
> Consequently, my handful of RSS readers were inundated with duplicated
> posts from yesteryear.
>
> However, while the proposed change would have enabled me to avoid
> this, I've go to say that most of my minor, typo correcting edits are
> relatively infrequent.
>
> I think these additional check-boxes would just be irritating noise on
> the 'blank canvas; of the article editor.
I absolutely agree that any addition to the publish UI should be
vigorously opposed, to ensure that only the most essential changes
happen. However, bear in mind that the option will only be visible
when editing pages with published status[1], and given that these edits
are relatively infrequent you wouldn't see it very often. I think the
clever UI people here could come up with a sensitive way to do this[2].
[1] hmm, that's fine if we've only got published and draft, but gets
more complicated if other statuses are added.
[2] perhaps a checkbox isn't the right control. Maybe it should be an
extra button, save and update (or something sensible those clever
people come up with).
Scott Merrill
> On Fri, Feb 15, 2008 at 03:28:05PM -0800, Andy C wrote:
> > I think these additional check-boxes would just be irritating noise on
> > the 'blank canvas; of the article editor.
>
>
> I absolutely agree that any addition to the publish UI should be
> vigorously opposed, to ensure that only the most essential changes
> happen. However, bear in mind that the option will only be visible
> when editing pages with published status[1], and given that these edits
> are relatively infrequent you wouldn't see it very often. I think the
> clever UI people here could come up with a sensitive way to do this[2].
My vision is a single checkbox inside the pagesplitter options portion
of the screen. It might have a tooltip, or a help icon next to it,
providing (or linking to) additional explanation as to the
implications of checking or blanking this box. It should only be
visible on items that are published.
> [1] hmm, that's fine if we've only got published and draft, but gets
> more complicated if other statuses are added.
It might be neat if we had a way to determine which content types
and/or statuses appear in feeds, and then only display the UI when
editing those items, while suppressing it from items that would not
appear in a feed.
> [2] perhaps a checkbox isn't the right control. Maybe it should be an
> extra button, save and update (or something sensible those clever
> people come up with).
I am strongly opposed to another button. I'm opposed to the presence
of two buttons, as it is now!
Michael C. Harris
>
> On 2/15/08, Michael C. Harris <michael...@gmail.com> wrote:
> > On Fri, Feb 15, 2008 at 03:28:05PM -0800, Andy C wrote:
> > > I think these additional check-boxes would just be irritating noise on
> > > the 'blank canvas; of the article editor.
> >
> >
> > I absolutely agree that any addition to the publish UI should be
> > vigorously opposed, to ensure that only the most essential changes
> > happen. However, bear in mind that the option will only be visible
> > when editing pages with published status[1], and given that these edits
> > are relatively infrequent you wouldn't see it very often. I think the
> > clever UI people here could come up with a sensitive way to do this[2].
>
> My vision is a single checkbox inside the pagesplitter options portion
> of the screen. It might have a tooltip, or a help icon next to it,
> providing (or linking to) additional explanation as to the
> implications of checking or blanking this box. It should only be
> visible on items that are published.
I thought hidden was good too, but "Yes, I've made a major edit" isn't
really a "setting", is it. I don't feel strongly about that though.
> > [1] hmm, that's fine if we've only got published and draft, but gets
> > more complicated if other statuses are added.
>
> It might be neat if we had a way to determine which content types
> and/or statuses appear in feeds, and then only display the UI when
> editing those items, while suppressing it from items that would not
> appear in a feed.
That sounds good.
> > [2] perhaps a checkbox isn't the right control. Maybe it should be an
> > extra button, save and update (or something sensible those clever
> > people come up with).
>
> I am strongly opposed to another button. I'm opposed to the presence
> of two buttons, as it is now!
In fact, I'd like another couple of buttons, and some checkboxes, and
a select box, and .... ;)
cheers, Michael
Sean T. Evans
>
> In fact, I'd like another couple of buttons, and some checkboxes, and
> a select box, and .... ;)
>
A Pony?
Michael C. Harris
Maybe a wildebeest. With radio buttons.
Geoffrey Sneddon
On 15 Feb 2008, at 18:42, Scott Merrill wrote:
> ITEM ONE
> We currently store two different time formats in the post table:
> pubdate is a DATETIME
> updated is a TIMESTAMP
>
> According to some documentation I've read, TIMESTAMPs have an upper
> bound in the year 2037.
It's actually 2038, not 2037, but that's only an issue as long as we
use 32-bit signed integers: on 64-bit PHP you have an issue in year
292,277,026,596 (which is likely past the end of the universe, so is
irrelevant). I'm not sure how 64-bit MySQL copes, though.
> I propose that we standardize on DATETIME for all time values to be
> stored in the DB. Your thoughts?
This has an issue in 9999-12-31, and can't be changed in a backwards
compatible way. In all seriousness, we have an issue with TIMESTAMP in
just under 30 years time on any 32-bit setups; and we have an issue
with DATETIME in 9999-12-31, if anyone is still using Habari then
(unlikely), so we ought to go for DATETIME everywhere.
> ITEM TWO
> The Atom Syndication format suggests that we return entries sorted by
> the updated time.
No, the Atom Syndication Format [RFC4287] makes no mention of how they
should be sorted, at all.
> We currently set the "updated" value in the DB for
> an edit, no matter how small.
This is in violation of the Atom Syndication Format, which defines
"the most recent instant in time when an entry or feed was modified in
a way the publisher considers significant".
> This means that fixing a typo in a post
> from two years ago will send that post to the top of your Atom feed.
Which is undoubtedly wrong: as someone who does often edit old posts,
I doubt my users partially care about a typo in a post from three
years ago.
> The Atom Publishing standard suggests that when fetching a list of
> entries, they be sorted by their edited value, where "edited" means
> "any edit, regardless how substantial".
It's not so much a suggestion, as [RFC2119] redefines the word
"SHOULD" as meaning "mean that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before choosing
a different course". It also states that "Atom Entry elements in
Collection Documents SHOULD contain one app:edited element".
I do not, in either case, see we have a valid reason in our
circumstances to ignore the SHOULD.
> Geoffrey Snedders has suggested that we add a third timestamp column
> to the post table to hold the value of the last minor edit. This
> field, "edited", would be updated any time a post is edited, for any
> reason.
> The "updated" column in the DB would be used to store the time of that
> last major edit.
> The "pubdate" column would store the original publication date.
>
> In order to effect this change, in addition to the new column, we
> would need UI on the post composition screen allowing an author to
> indicate whether an edit is minor or not. I suggest a single
> checkbox, labeled "This is a minor edit" that is checked by default.
> I believe it to be the case that most people will correct typos more
> often than they make a major change to a post.
>
> What do folks think about extending the schema to include a new
> "edited" column?
> What do folks think about adding a checkbox to the post composition
> screen?
This still, to me, seems like the only sensible solution.
The other importance that this change makes more obvious is that the
Atom Syndication Feed and Atom Publishing Protocol collection need to
be in separate documents, as they have different sorting requirements.
--
Geoffrey Sneddon
<http://gsnedders.com/>
Ben Ramsey
> The other importance that this change makes more obvious is that the
> Atom Syndication Feed and Atom Publishing Protocol collection need to
> be in separate documents, as they have different sorting requirements.
I see no need for them to be separate documents.
Section 4.1.1 of RFC 4287 states "this specification assigns no significance to
the order of atom:entry elements within the feed." So, I don't see where the
Atom Syndication Format specifies how entries should be ordered. AtomPub simply
takes this a step farther by actually assigning significance to the order,
stating in section 10: "Entries in the returned Atom Feed SHOULD be ordered by
their 'app:edited' property, with the most recently edited Entries coming first
in the document order."
To me, this doesn't warrant a distinction between Atom Syndication Feeds and
Atom Protocol Collections. Section 10 of the protocol also states: "No
distinction is made between Collection Feeds and other kinds of Feeds." To me,
this means that they should be treated exactly the same. The Protocol simply
adds a few more rules to Feed.
--
Ben Ramsey
http://benramsey.com/
Owen Winkler
>
> My vision is a single checkbox inside the pagesplitter options portion
> of the screen. It might have a tooltip, or a help icon next to it,
> providing (or linking to) additional explanation as to the
> implications of checking or blanking this box. It should only be
> visible on items that are published.
I was not clear in my last message, so I'll try again. I concur with
the thought that the new updated field and a control to access it are
required; However, using only a checkbox limits the functionality and
doesn't adequately characterize the purpose of the control.
The purpose and effect of the control should be clear to the author
without reading additional tooltips or help. As described, the checkbox
has no obvious effect on feeds, which is its sole current purpose. It
also offers no explanation for what it does or where its value might be
used when the post is saved, compared to every other control on the page.
The control should let an author set a date because it is controlling
the value of a datetime field in the database, not a boolean value.
Habari can make it easy to set this field to the current date by using
javascript via a nearby link or button labeled "set 'updated' to current
time" or similar. We already provide a date field for publish date, so
it seems reasonable we should do the same for the updated date.
Alternate content types that choose to use the default composition page
rather than a custom one have de facto made the decision to provide the
updated field, whatever it might look like. The database field is
already present and valid for storage for all content types, so it
offers no danger being displayed on the composition page. Even if the
alternate content type uses the default composition page, it is possible
to remove the field from it using the publish_controls filter. As a
result, there is no reason for core code to determine whether to display
this individual field based on a post's content type.
Owen
Geoffrey Sneddon
currently uses one feed for both end users and the APP collection, and
is currently sorted by atom:updated (which is currently any update,
but seems to be little opposition to fixing that) — the seeming issue
is splitting the end user feed and the APP collection up, as several
are questioning what the need to actually order by app:edited is. What
really is the need for it to be ordered by app:edited? I can see
nothing in the archives or on the wiki about the ordering (apart from
its introduction).
On 16 Feb 2008, at 18:54, Ben Ramsey wrote:
> On 2/16/08 6:54 AM, Geoffrey Sneddon wrote:
>> The other importance that this change makes more obvious is that the
>> Atom Syndication Feed and Atom Publishing Protocol collection need to
>> be in separate documents, as they have different sorting
>> requirements.
>
> I see no need for them to be separate documents.
>
> Section 4.1.1 of RFC 4287 states "this specification assigns no
> significance to
> the order of atom:entry elements within the feed." So, I don't see
> where the
> Atom Syndication Format specifies how entries should be ordered.
> AtomPub simply
> takes this a step farther by actually assigning significance to the
> order,
> stating in section 10: "Entries in the returned Atom Feed SHOULD be
> ordered by
> their 'app:edited' property, with the most recently edited Entries
> coming first
> in the document order."
I didn't mean ASF actually required any specific order, I meant that
for end users it makes no sense to order the end user feed by
app:edited (as nobody cares about a typo from several years ago being
corrected, for example); we have no valid reason in our circumstances
to order the APP collection (by app:edited) against the "SHOULD" in
APP, so in that way they have conflicting needs. This means they need
to be separate documents.
> To me, this doesn't warrant a distinction between Atom Syndication
> Feeds and
> Atom Protocol Collections. Section 10 of the protocol also states: "No
> distinction is made between Collection Feeds and other kinds of
> Feeds." To me,
> this means that they should be treated exactly the same. The
> Protocol simply
> adds a few more rules to Feed.
Yeah, sure, it's possible to have them as the same, but to follow what
APP actually says you need it ordered by app:edited, which makes no
sense in the context of a normal feed that readers subscribe to.