[oslc-core] ChangeLog Proposal Finalization

Thu Mar 31 10:37:29 EDT 2011

Frank, thanks for clarifying.  I had completely missed the fact that the 
change log entries were going to be returned with latest sequential entry 
first.  As you said in a separate response, a client can be lazy and only 
request pages till it gets entries that have been processed.

I agree that some of the other optimization and filtering type 
improvements can be introduced later as need arises.  The current proposal 
should at least functionally provide the capabilities for the scenarios I 
was thinking of.

Frank Budinsky <frankb at ca.ibm.com> wrote on 03/31/2011 08:46:58 AM:

> From: Frank Budinsky <frankb at ca.ibm.com>
> To: Samit Mehta/San Francisco/IBM at IBMUS
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 03/31/2011 08:46 AM
> Subject: Re: [oslc-core] ChangeLog Proposal Finalization
> 
> Hi Samit,
> 
> oslc-core-bounces at open-services.net 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:
> > 
> > oslc-core-bounces at open-services.net
> > 
> > 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:samit.mehta at us.ibm.com
> > IBM Rational Software - Business Development
> > 
> > 
> > oslc-core-bounces at open-services.net wrote on 03/29/2011 11:26:13 AM:
> > 
> > > From: Frank Budinsky <frankb at ca.ibm.com> 
> > > To: oslc-core at open-services.net 
> > > Date: 03/29/2011 11:29 AM 
> > > Subject: [oslc-core] ChangeLog Proposal Finalization 
> > > Sent by: oslc-core-bounces at open-services.net 
> > > 
> > > 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
> > > Oslc-Core at open-services.net
> > > 
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
> > _______________________________________________
> > Oslc-Core mailing list
> > Oslc-Core at open-services.net
> > http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110331/b9a4d485/attachment-0003.html>