[Ocs] Proposal: Update handling for the lists

[Laszlo Papp]

Hi,

It would be nice if OCS had a precise and concise way of handling the
updates for the list items. This would be useful for clients because they
would not need to fetch the whole list again, just the new or modified list
items. This could also aid the clients for having notifications for the new
items without making a full comparison between two fetched list. They could
just get the count out of
the freshly fetched items.

Disclaimer: the reasoning behind the one-liner change for each relevant
service is quite long, consisting of all the available alternative
approaches that came to my mind. If you would like to skip the detailed
reasonings, just read the gist right below.

==================================================================================

Summary

Due to all the reasoning in the details, I would like to go for the date
and time variant for now. This could be used for at least the following
services: activity, content, fan, knowledgebase, event, comments, forum,
and achievements. Some of them do not yet contain a changed date and time
attribute which would be very useful and straight-forward to amend. Please
find my proposal below.

list

* URL Arguments: afterdate - the date and time where you want to get the
comments from.

Any feedback is welcome as usual.

Laszlo



==================================================================================

Details

I was initially thinking of a few approaches for this subject:

* new optional url argument to the list query for getting the items of the
list after the certain entry identifier

    a) Getting all the new updates may be problematic, including that if
the given entry was edited, not just if a new entry is added. In other
words, the date and time would be necessary to present for getting the
updates for the entry specified by the identifier passed.

    b) Currently the specification does not specify if the entry
identifiers should be starting for instance from one and then upwards
(parents and children logic included). As far as I see, this is not set in
store in OCS to have this incremental order. Hence, the servers could not
necessarily provide the information right apart from the date and time.

* new optional url argument to the list query for getting the items of the
list after the certain entry modification date and time

   a) This would provide a precise result, as far as I can tell, because
the client could fetch all the updates happened after the provided date and
time including the entry additions and edits. The date and time could be
handled as a modification date, including the creation for sure.

   b) This would not be useless either way because as OCS already works, it
is possible to filter the fetched list according to the existing
attributes. This is not yet specified for all the attributes existing, but
it is there for some, already. The date and time would be a logical and
reasonable addition in my opinion to that filtering.

   c) This addition would also cover the feature for not just getting all
the updates, but also the updates for instance in the last 24 hours, today,
and so forth.

   d) The date and time format is already clearly specified by OCS:

   "Date Format

   All date and time data is in ISO 8601 format."


* new query for getting all the updates

    a) This would be more intrusive introduction to the specification than
the aforementioned ideas.

    b) Even if it is called somehow like "updates" query, this would
actually be a filtered list fetching which could bring confusion to the
specification implementations.

    c) It would most likely need to have the overlap with the other url
arguments for the list query. This would be an unfortunate duplication,
hence confusion and maintenance overhead.

* boolean attribute for tagging an entry is added or updated

    a) It is not possible to do this in a client independent manner. For an
entry is tagged as updated or added after such an activity. Then, one
client would request the updated items, but what would the server do with
the attribute? Would it tag as non-updated or non-added? Then, other
potential clients may lose the information. If the server leaves the
attribute as updated or added, the previously mentioned client would fetch
the entry again.

    b) This could probably be solved with a client identifier on the server
side, but it would be already more complex than necessary, and probably out
of the scope for the standard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/ocs/attachments/20120828/4e90b615/attachment.html>