On Sat, Oct 20, 2007 at 09:56:50PM -0000, Andrew da Silva wrote:
> On Oct 18, 7:09 pm, "Michael C. Harris" <michael.twof
...@gmail.com>
> > * Atom and AtomPub share a URL
> > While this works okay, because Habari uses the presence of
> > authentication details to tell the difference between a request for a
> > feed and a request for an AtomPub service document, it relies on the
> > client sending a correct username and password with the initial
> > request. If the client wants a service document and they don't send
> > authentication, they'll get a feed instead of a 401 authentication
> > challenge.
> > Solution: Provide a separate URL for the service document, probably
> > /atom/service.
> At this point, we should split both protocols since the class is
> getting big, confusing and contains methods not related to the Atom or
> AtomPub.
I don't see a problem in splitting Atom and AtomPub, but there will
likely be some things that are common to both, see my comment about
DRY. Something like atomhandler.php, atompubhandler.php and
atomutils.php? We'll have to have a close look at this.
> Where could we put RSD though? Is RSD considered a microformat? Maybe
> we could create a microformathandler.php? (And implement other
> microformats)
It's not a microformat, it's just a simple XML format (microformats
are vocabularies designed to be embedded in other XML documents,
usually XHTML). I don't know where it should go, but I think it's
important. Hmm, maybe it shouldn't be atomutils.php, it should be
serviceutils.php and RSD should go in there.
> As for the URLs, we current use /atom for the service document
> (introspection).
> I dislike the use of /1 for our main feed. You suggest /service for
> the service document, I think /atom is fine. But we should rename /1
> to /atom/feed.
I think you mentioned that the 1 was the blog id for multisites? I
don't know enough about that, but maybe it is important. When we get
deeper into things I'll test against multisites. More investigation
and thinking required here I think.
> As for the AtomPub "API" URL, we could use /atompub or /atom/api? /
> atom/app? /app?
I would vote for /atompub. I'm very strongly opposed to anything that
uses API, because the Atom API was basically a previous version of
AtomPub and it just creates confusion.
> > * PHP as a CGI
Patch attached to issue 467.
> > * Support WSSE authentication
> > Habari currently supports only HTTP Basic Authentication. Some clients
> > and devices only implement WSSE Authentication, such as the Nokia N73.
> > Solution: As a proof of concept in the past, I implemented WSSE in
> > WordPress. One slight catch, and the reason it didn't work in
> > WordPress, is that WSSE requires plain text passwords to be
> > retrievable on the server. Are they available in Habari? If so, it
> > should be trivial for me to write a patch.
> Like I told you last night, I do not know WSSE, at all. That is why I
> left the code as-is and did not even bother reviewing it.
> You told me you implemented (or worked on) WSSE in Wordpress. Would
> you be ready to implement it in Habari?
Does Habari store user passwords in a retrievable form? If I can get
a user's password, I could implement WSSE pretty quickly.
> > * AtomPub categories support
It's done, there's a patch attached to issue 455.
> > * AtomPub draft support
> > Habari does not currently support the AtomPub protocol provision for a
> > client to send a request for an atom entry to be considered a draft.
> > Solution: Detect the app:control element in atom entries and honour
> > the app:draft setting, where a value of 'yes' means the entry is a
> > draft.
> We could work on a patch to implement that ASAP.
This is now issue 466.
> > * AtomPub summary support
> > I'm not sure I've got a handle on this one completely. In the section
> > entitled Media Link Entries, the AtomPub spec says, "[RFC4287]
> > specifies that Atom Entries MUST contain an atom:summary element" but
> > the Atom spec clearly says in both the (normative) text and
> > (non-normative) RelaxNG fragments that atom:summary is optional. The
> > Atom spec says, "It is advisable that each atom:entry element contain
> > ... a non-empty atom:summary element when the entry contains no
> > atom:content element." So, given an uploaded media entry, Habari may
> > create a summary element for the media link entry associated with the
> > media entry.
> > Solution: I don't really see any way of producing a summary
> > automatically. I think the only thing we can do is to support summary
> > elements provided by the client. As file uploads has not yet been
> > implemented, it's trivial to add a summary column when it is.
> I believe we once received a feature request to implement "excerpts"
> for posts. If we were to add that feature, that could be used as the
> summary. If no excerpts exist, just use the "more" function to
> retrieve the first 200 words or so?
That sounds reasonable, but the Atom spec says, "It is not advisable
for the atom:summary element to duplicate atom:title or atom:content
because Atom Processors might assume there is a useful summary when
there is none." When I get a chance, I'll get on #atom and ask whether
this is a wise idea, or whether we should just not include a summary
element when there is none specifically assigned.
> 7. Support foreign markup delivered by AtomPub
> This is out of my league for now. Geoffrey may be a resourceful
> person?
I think we keep this on the backburner until we've sorted out the
other issues.
> > * Decouple app:edited and atom:updated
> > Atom entries can have a client provided atom:updated element. The
> > purpose of this element is to signify that a _significant_ change has
> > been made to the entry. AtomPub provides the app:edited element, which
> > is a timestamp representing the last time that the entry was changed
> > in any way. An AtomPub server can override the atom:updated value and
> > use its own, which Habari currently does. Habari's Post class's
> > updated column is written on all edits and is used to fill app:edited
> > elements.
> > Solution: Create an edited column for the Post class, and use this to
> > populate app:edited, and use the client provided atom:updated value
> > (or a timestamp if it isn't provided) to fill the updated column. This
> > would have the side effect that with a small UI change in admin, users
> > could mark things as minor edits, such as fixing typos or adding tags.
> > However, changing Post would also have far-reaching consequences. We
> > could also sort the atom feed by atom:updated, as this makes semantic
> > sense and order is not mandated in the Atom spec, and still have
> > AtomPub sending in app:edited order.
> I fully support the idea of adding an option on the publish page to
> specify if the editing is minor. Adding the "edited" column to the
> schema should not be a problem if we see it fit.
> But I still find it weird to store 3 different timestamps, just to
> clear my mind:
> - Publication date
> - Last any type of update (current :updated)
> - Last major update (would be :edited)
Not quite, :updated would be last major updated and :edited would be
last any type of update.
> Couldn't we use "updated" for both, just have the option "minor edit"
> decide if we update or not that value/timestamp?
No, we can't. According to the spec, app:edited MUST be updated on all
edits. So, to implement minor edits, and to support sorting the feed
differently than the collection, we need to have separate columns.
> 9. Atom media collection support
> Since this depends of our media implementation, we should wait for
> Owen to complete his work on that feature and then work out the best
> solution. Let's focus on the other issues we can fix now.
Agreed 100%.
> 10. get_collection and get_entry currently violate DRY
> Indeed, it does violate the "do not repeat yourself" rule. One way
> could be to have get_entry support a parameter $return.
> If $return, do not add response struct and headers. Return the "entry"
> struct only.
> If not $return, add the response struct and headers. Output the
> response.
We can sort this out when we split the atom and atompub
implementations.
cheers, Michael
--
Michael C. Harris
School of CS&IT, RMIT University
