[oslc-core] New OSLC ChangeLog Proposal

Tue Jan 4 12:23:52 EST 2011

Thanks for the feedback Steve. I added a couple more comments after
Martin's. See <FB></FB>

Thanks,
Frank.

  From:       Martin Nally/Raleigh/IBM at IBMUS                                                                            

  To:         Steve K Speicher/Raleigh/IBM at IBMUS                                                                        

  Cc:         Frank Budinsky <frankb at ca.ibm.com>, oslc-core at open-services.net                                           

  Date:       01/04/2011 10:16 AM                                                                                       

  Subject:    Re: [oslc-core] New OSLC ChangeLog Proposal                                                               

See <mn></mn>

Best regards, Martin

Martin Nally, IBM Fellow
CTO and VP, IBM Rational
tel: +1 (714)472-2690

  From:       Steve K Speicher/Raleigh/IBM                                                                              

  To:         Frank Budinsky <frankb at ca.ibm.com>                                                                        

  Cc:         Martin Nally/Raleigh/IBM at IBMUS, oslc-core at open-services.net                                               

  Date:       01/04/2011 09:50 AM                                                                                       

  Subject:    Re: [oslc-core] New OSLC ChangeLog Proposal                                                               

> From: Frank Budinsky <frankb at ca.ibm.com>
> To: oslc-core at open-services.net
> Cc: Martin Nally/Raleigh/IBM at IBMUS
> Date: 12/20/2010 10:47 AM
> Subject: [oslc-core] New OSLC ChangeLog Proposal
> Sent by: oslc-core-bounces at open-services.net
>
> Hello,
>
> Nick Crossley and I would like to submit a proposal for adding a
ChangeLog
> service to the OSLC core specification. This new service will be key to
the
> success of an indexer, and therefore we would like to queue it up for
> discussion as soon as possible in January.
>
> The OSLC proposal, itself, is described in section 1.5 of the attached
> document, while the rest of the document describes an indexer prototype,
> including how it intends to use the change log.
>
> (See attached file: RDF_indexer_overview_1220.doc)
>
> Any comments/feedback on the new proposal or the indexer prototype itself

> would be very welcome.
>

Hi Frank,

Proposal seems quite simple and workable.  Some initial comments on the
proposal:

Though I would have expected that a client could request a date range for
the change log, or simply "changes since some date time".  Whether some of
the query syntax could be used or simply using name-value pair on changelog
service URI such as ?oslc.since=mmddyy or something.

<mn>Several people have requested this. The current thinking is that so
long as the pages are inverse-time-ordered, clients have enough mechanism
already to satisfy this need. So far this has indeed been adequate for the
prototype implementation. I would prefer to avoid adding more options until
we have a client that can explain in detail why the current solution is
inadequate.</mn>

<FB>We also think that adding an optimization like this in the future would
be simple. Removing or changing it later would be much harder.</FB>

Why is an ordered collection important if you have oslc:at (timestamp) with
each entry?  Is it expected that clients need to validate oslc:at match the
order?  I suspect the answer is that in order for the indexer to properly
process paged responses, it would like to start with first page received
and not have to fetch all pages to validate order.

<mn>Interesting point. I think there are two possible conceptual models.
One is that a change-log is inherently time-ordered. In that model, you
would expect the representation to reflect that characteristic, and you
would not need features like "?oslc.since=mmddyy" since retrieving the
pages in reverse time order gives you the same result. This is the
conceptual model that underpins the current proposal. The other conceptual
model is that the change log is just a set of entries with time-stamps,
which is the mental model you seem to be working with. Features like "
?oslc.since=mmddyy" are necessary in that model to select a subset that has
the characteristic that all other entries are guaranteed to be older or
younger than all the entries in the subset. I think your model is probably
a workable alternative. I can't think of a compelling reason for adopting
one over the other, although my bias is still towards the current
proposal.</mn>

<FB>A possible benefit of the current proposal is that it might be simpler
and/or more efficient for a service provider to truncate the ChangeLog if
the entries are maintained in a time ordered list.</FB>

Would you expect that each occurrence (change event) be possibly a
URI-addressable resource itself?  Proposal seems to imply it is not in your
proof of concept but could imagine implementations where it is.  Not sure
there is any issue with this, just an observation that may be worth noting.

<mn>The current design does not preclude URI-addressable change entries,
but does not require them. If a client had to GET the change events
individually to access their properties, it would have a significant
performance impact.</mn>

It would be interesting when we have this discussion to look at the
scenarios where we are interested in change log for a given resource, for
example "history of a defect", to see how these models should compliment
each other.  As Olivier alluded to in his response, there could be cases
where it might be helpful to extend this to include more detail about the
change.

<mn>Changelogs have been around for a long time, and the scenarios they are
used for are fairly well understood. It's not conventional to try to
implement resource-specific change logs, and I'd be nervous about going
down that path. Also, if you start to put "detail" in a change log, you
will have to invent a security model for the change-log, which I think will
lead to complexity. I don't think we should go there.</mn>

Would be good to stick to Dublin Core, for example dc:date instead of
oslc:at. <mn>Yes, I like that idea.</mn>  Not sure there are good matches
for any of the other properties.

<FB>Thanks for pointing this out. I'll make this change right away.</FB>

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110104/2caafd4c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110104/2caafd4c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110104/2caafd4c/attachment-0001.gif>