Hi Samit, [email protected] wrote on 03/29/2011 08:20:51 PM:
> [image removed] > > Re: [oslc-core] ChangeLog Proposal Finalization > > Samit Mehta > > to: > > oslc-core > > 03/29/2011 08:22 PM > > Sent by: > > [email protected] > > Hi Frank, > > I wanted to clarify the following regarding your proposal for the ChangeLog. > > Based on my understanding is that the OSLC client wishing to build a > queryable index would: > a) query the resources using simple queries that are already > documented by OSLC specs > b) use the change log URI to get "notified" of changes to > that service provider's resources > > Wouldn't there be a significant overlap of the data returned by each > HTTP GET of the Change Log URI? If a server doesn't truncate the > log for say seven days, then over that period the change log would > keep growing and will include a large number of change log entries > that were already processed by the client. You're basically correct, but the ChangeLog is divided into pages, so typically it will only retrieve the first page. Yes, that will include a number of change log entries that were previously processed, but we don't think it will be such a large number that the increased size of the message will have any affect. > > Did I misunderstand your proposal? Couldn't we design something > where the client has more control over what change log entries are > returned - e.g. specify that the provider return the change log > entries with entry sequence number greater than X, where X is the > entry sequence number of the sequentially last change log entry that > client has already processed? We've considered this, but decided to keep it simple for now. We can always add this in the future, as an optimization, if we discover that always returning a full page of entries is too much. > > Also, would you agree that the proposed change log could be used for > integration scenarios where an OSLC client is needing to react to > changes to a set of resources? In such cases, it would be useful if > the OSLC client could specify the list of resources (especially if > it is a small set) that it is interested in monitoring changes to - > i.e. the client could specify that the change log entries associated > to a specified set of resources be returned. Since we want this to be as easy as possible for a service provider to implement, we didn't want to introduce any kind of resource filtering requirement in the design (at least not initially). So this means the client needs to work with the full ChangeLog and ignore any resources it's not interested in. If that turns out to be too inefficient, we can consider optimizing it in the future. Thanks, Frank. > > Regards, > ____________________________________________ > Samit Mehta > (512) 323-9350 - Work > mailto:[email protected] > IBM Rational Software - Business Development > > > [email protected] wrote on 03/29/2011 11:26:13 AM: > > > From: Frank Budinsky <[email protected]> > > To: [email protected] > > Date: 03/29/2011 11:29 AM > > Subject: [oslc-core] ChangeLog Proposal Finalization > > Sent by: [email protected] > > > > Hi all, > > > > We're very close to finalizing the OSLC ChangeLog proposal. The last > > three issues, which are still being discussed are: > > > > 1. Indexing/ChangeLog resources/scope > > Latest email: http://open-services.net/pipermail/oslc-core_open- > > services.net/2011-March/000898.html > > > > 2. ChangeLog Pagination (also URI-addressable ChangeLog entries) > > Latest email: http://open-services.net/pipermail/oslc-core_open- > > services.net/2011-March/000893.html > > > > 3. Better name for OSLC indexing profile > > Latest email: http://open-services.net/pipermail/oslc-core_open- > > services.net/2011-March/000896.html > > > > We're planning/hoping to finish the discussion of the ChangeLog > > proposal at tomorrow's OSLC WG meeting, so please send any > > additional comments or ideas that you have by replying to this or > > one of the discussion thread emails. > > > > Thanks to everyone that has provided input so far. > > > > Frank._______________________________________________ > > Oslc-Core mailing list > > [email protected] > > http://open-services.net/mailman/listinfo/oslc-core_open-services.net > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
