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.