[Ocs] Proposal: Update handling for the lists

[梁辰晔]

Hi,

I think it will bring confusion to add 'afterdate'.
For example,
    list with page=1, pagesize=10, afterdate = yesterday, search=foo.
Your mean:
    the server should 1) search item=foo
                             2) find page=1&pagesize=10
                             3) find afterdate item
But the first impression (for me):
    the server should 1) search item=foo & find afterdate item
                              2) find page=1&pagesize=10


How about add another URL to work with it
URL Arguments: ids - Ids of the requested content ids seperated by "x".
Thanks,
David


2012/8/29 Laszlo Papp <lpapp at kde.org>

> 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.
>
> _______________________________________________
> Ocs mailing list
> Ocs at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ocs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/ocs/attachments/20120831/db6dae46/attachment.html>