Archived Discussions
[DavidJanes] I'm using this page to place "archived" or moot discussions from AggregatorApi
Richer Operations
This is the place for discussing how to deal with deleted entries, modifications of subconent (like comments and stuff) etc.
[KenMacLeod] I'm not sure where this fits in this discussion. I sketched out a query-result in a message to the Syntax mailing list. The result-set in that email was for "what entities refer to this URI", to get all comments and references to a particular entry or other resource. The same thing could be used for If-Modified-Since or other queries.
-
[DavidJanes RefactorOk] Actually, there's some ties in with James' comment above with the 'last-updated=' stuff. We need to define additional attributes (under our own namespace?) that extend the feed. Not only 'last-updated' but also 'deleted', for example, so we can really send differences. Note that this is a higher level of functionality than what I would consider we should provide at the base. Furthermore, we need to be able the parameterize the get(s) to say "give me the comments", "give me who linked to this article", "give me the trackback pings", etc.
[JamesAylett RefactorOk] While I like the richness of that, I worry that not all producers (ie: feed software, like MovableType or whatever) will want to implement that level of complexity.
[JamesAylett RefactorOk] Deleted entries isn't something we've considered so far. I think that needs quite a bit of thought ...
Levels of service
Consider the following levels of service
-
Level 0: reading flat Necho/XML files -- i.e. no service at all
-
Level 1: incremental updates that efficiently provide the equivalent of reading flat Necho/XML files
-
Level 2: incremental updates that allow (or allow efficient):
-
deletion of objects
-
partial modification
-
modification of subcontent
[JamesAylett DeleteOk RefactorOk] I'm not convinced having level 1 and 2 distinct is a good idea. I think we're going to end up with the only thing in level 2 not in level 1 being deletions, which is going to be ignorable anyway. So we should probably end up with level 0 == main feed, level 1 == AggregatorApi, and get rid of the terminology again. We'll need to reword things higher up so get-entries-since-timestamp becomes get-changes-since-timestamp, or something. This may impact on how we bind in to Joe's work, though, since he's considering getting entries (and/or comments), not changes, which alters the semantics somewhat. On the other hand, we needed to do that anyway if we wanted to get updated entries.
-
[DavidJanes] If there's no "addto" operation, there's no need to define the Levels of operations, exactly as you say. I just want to be 100% convinced that we can incrementally add a comment (for example) without resending the entire entry! If we're all on the same page here, I'll archive this entire discussion onto another page as moot.
-
[JamesAylett RefactorOk] The way the comment-as-entry discussion is going, the hierarchy is implicit - it's not spelled out in the XML (so <entry id='345'/><entry id='346' parent='345'/> rather than <entry id='345'><entry id='346'/></entry>). That certainly means we can add/update/remove comments exactly as entries, without having to send any information beyond the object in question.
Example
Consider the following object (purely illustrative XML -- it's not trying to conform to anything).
<item id="123"> <created>2000.01.01-12:00:00</created> <author>David Janes</author> <content>This is a weblog entry (15000 other bytes of content not shown)</content> </item>
To update, we can just resend the object
<item id="123"> <created>2000.01.01-12:00:00</created> <modified>2000.01.01-12:10:00</modified> <author>David Janes</author> <content>This is my favorite weblog entry (15000 other bytes of content not shown)</content> </item>
However, how to we delete it? (Discuss)
<item id="123" action="delete"> </item>
Now, consider the case where we're sending the comments along also
<item id="123"> <created>2000.01.01-12:00:00</created> <modified>2000.01.01-12:10:00</modified> <author>David Janes</author> <content>This is my favorite weblog entry (15000 other bytes of content not shown)</content> <comment> First Comment </comment> </item>
What happens when a second comment comes in? It's not a modification to the main content, yet we need to indicate this somehow. My suggestion:
<item id="123" action="addto"> <comment> Second Comment </comment> </item>
Discussion
[JeremyGray RefactorOk] I think we would be well-advised to directly leverage or at least mimic the work being done on the PieApi. Are the above samples necessary or desirable for illustrating something not covered by the PieApi? If so, would this be something that has simply not yet been covered by the work on PieApi? Or something that would never need to be covered by the PieApi?
-
[DavidJanes RefactorOk] They were designed to be illustrative for the points below. If you'd like to rewrite them to conform to whatever's in the PieApi, or point me to the appropriate text, please. You're obviously seeing something different over there than I am. For example, where in the PieApi does it show how to indicate that an entry was deleted at some point in the past? Perhaps a little more clarity on my part: the information returned from the retrieve operations is telling us about things that have happened, not stuff we want to happen.
-
[MartinAtkins : RefactorOk] I was under the impression that comments and trackbacks are now to be considered entries, which just happen to have one (or more?) parent entries. Comments being just entries makes things a lot easier; it's not unlike the threading of USENET.
-
[DavidJanes DeleteOk] Interesting. If this is so, is there any sense in having an "addto" operation, given that it would be used so infrequently, it probably wouldn't be implemented correctly anyway?
-
[MartinAtkins : DeleteOk] No, we don't really need addto at all. The producer just needs to send an entry which has the correct parent. Given that entries have globally-unique identifiers, this theoretically means that one feed could add replies to another. This is starting to sound more and more like USENET.
[JamesAylett RefactorOk] References: PieApi section 2.5; Joe's draft section 5.8; IsaCommentAnEntry (summary: yes); CommentEntryExample where people are discussing how it'll look.
-
[DavidJanes DeleteOk] Argggg, I was just showing <comment> to illustrate the possible need for an "addto" operation! I'm not trying to redefine work going on elsewhere.
-
[JamesAylett RefactorOk] Sorry, I wasn't terribly clear. The references are places where it's been discussed that comments can be modelled as entries. (Similar discussions are ongoing for things like Trackbacks.) The XML element in question is still slightly up for grabs in those discussions, although I can't see a good reason why it won't end up just as <entry/>.
[DavidJanes, RefactorOk] In a Level 1 feed (and by implication, Level 0 feed), all actions are "insert/modify". A Level 2 feed adds the additional power to delete items and to partially modify objects.
[DavidJanes, RefactorOk] Question/statement: I may be wrong about delete, it may be a Level 1 op. The "addto" is something new.
[MartinAtkins : RefactorOk] It should also be made clear that delete and edit events may or may not be honoured, because as much as people would like to think they retain editorial control, the fact is that there's really nothing to stop people retaining previous versions. Mandating that they be honoured in the spec will just create a false sense of security.
-
[DavidJanes DeleteOk] +1 on the "clarity" part
[JeremyGray] All this talk of commenting seems premature. Are the examples showing how an aggregator is notified of these new comments and/or entry deletions? Because it could quite easily be interpreted as a set of examples as to how an application might perform the actual deletion of an entry and/or the submission of a comment. Clarification would be beneficial. Ignoring for the moment that commenting is more closely aligned to the editing portions of the API than the aggregation portions, we have not yet dealt with the aggregation portions themselves, which in my opinion need to come first. What we seem to be really lacking here is an exhaustive list of aggregation use cases so that we might walk through each determining how it would be best achieved.
-
{JamesAylett RefactorOk] Examples on this page should always be of data transferred from a producer to an aggregator, in that direction, and those examples make sense from that point of view. ie: they are commands from the producer to notify the aggregator of new/modified/deleted entries (or comments). This will naturally look a bit like an PieApi - however they've chosen to go down a highly RESTful route, so half the information we'll have to encapsulate in XML will be done in the PieApi at the HTTP level. I agree that comments are a distraction at this point (mostly because there's work being done elsewhere on harmonising that with the entry concept anyway).
[JeremyGray] Its also probably time to move beyond "illustrative XML" and use actual EchoExample-based forms and mechanisms which leverage or are at least clearly derived from mechanisms which exist in the PieApi at present.
-
[JamesAylett DeleteOk] +1
[DavidJanes DeleteOk] I'd like to archive this entire discussion, because as is clear from James' comments way up above, the addto is not needed. When we do more examples, we'll do it more like Necho.