UserPreferences

AggregatorApiArchived


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 [WWW]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.

Levels of service

Consider the following levels of service

[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.

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] 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.

[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.

[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.