[oslc-core] Oslc-Core Digest, Vol 11, Issue 23

Arthur Ryman ryman at ca.ibm.com
Wed Dec 15 16:00:43 EST 2010


Martin,

I used iPhone as an extreme case. I've seen many performance problems 
caused by services returning too much data to browser and desktop clients. 
 When you examine these problems, they are usually caused by users using a 
product in ways that the dev team did not expect or test. Some general 
mechanism that allows clients to limit the amount of data returned seems 
to be very well motivated by actual experience.

Paging is a standard solution to avoid sending all the data at once. 
Either we allow the client to advertise its limits, or we require the 
server to infer the limits based on other information such as the 
User-Agent. Are you proposing an alternative to the current design, or 
just that it be dropped?

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063





From:
Martin Nally/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
12/14/2010 07:27 PM
Subject:
Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23


I think the time to consider this would be when we had real experience 
from iPhone implementers suffering a problem, and a prototype showing that 
this is the simplest effective solution. It might seem like a good idea to 
anticipate solutions to "obvious" potential problems, but my experience is 
that this does not lead to good outcomes. Our ability to anticipate what 
the problems will really be and imagine likely solutions is much less than 
we think, and this sort of thinking leads to bloat and wasted effort on 
problems that turn out not to matter, or solutions that don't work. This 
sort of anticipation is what lean, Kanban and other popular methods tell 
you not to do.

Best regards, Martin

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





From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
Martin Nally/Raleigh/IBM at IBMUS
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
12/14/2010 06:35 PM
Subject:
Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23


Martin,

"?oslc:pagesize=n" is useful for clients that have limited bandwidth or 
processing ability. In practice, the size requested by a client is much 
smaller than what the server could generate. For example, an iPhone might 
request just 10 items per page whereas headless clients, such as ETLs or 
crawlers, might request 1000 items per page.

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063






From:
Martin Nally/Raleigh/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
12/10/2010 11:36 AM
Subject:
Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23


Yes, makes sense. See a separate note where I asked why we have 
"?oslc:pagesize=n". That is the only place I know where there is any 
suggestion that pages might be equal-sized. I'd be happy to get rid of 
that.

Best regards, Martin

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





From:
Arthur Ryman <ryman at ca.ibm.com>
To:
Martin Nally/Raleigh/IBM at IBMUS
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
12/10/2010 10:20 AM
Subject:
Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23



Martin,

The point that was bothering me was that it might be a burden on 
implementations to require that the number of pages and the RDF triples in 

each page are the same for all representations. 

For example, suppose an implementation imposes a limit of 1 MB per page. 
Suppose in Turtle you can pack 10,000 triples per MB, but in HTML you can 
only pack 1,000 triples per MB. Suppose a resource has 2,000 triples. The 
server could return then all in 1 page of Turtle, but would require 2 
pages of HTML. I am suggesting we allow that. Does that fit with your 
view?

Regards, 
___________________________________________________________________________ 


Arthur Ryman, PhD, DE

Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063





From:
Martin Nally <nally at us.ibm.com>
To:
oslc-core at open-services.net
Cc:
oslc-core at open-services.net, oslc-core-bounces at open-services.net
Date:
12/09/2010 03:30 PM
Subject:
Re: [oslc-core] Oslc-Core Digest, Vol 11, Issue 23
Sent by:
oslc-core-bounces at open-services.net



I agree with what you wrote, but it doesn't seem to contradict what I 
said.
There is something slightly comic about this conversation. I think you
provided a very clever insight that both simplifies and generalizes the
concept of paging, and now you seem to be arguing against your own clever
idea. I was worried that it was conceptually difficult to define what it
means to return the first half (or third, or quarter) of an HTML
representation. Your insight is that you do not have to worry about that -
you can define pagination in terms of the underlying RDF resource. There
are some minor complexities in "paginating" an RDF resource that has blank
nodes - all triples that reference the same blank node need to appear on
the same "page" - but otherwise paginating an RDF resource is conceptually
trivial. Representing those pages is now well defined - all you need is a
valid HTML, JSON, RDF/XML, Turtle or other representation of the page,
which is itsefl a well-defined RDF resource. No special specification or
documentation is required. It's a very simple, elegant model - go to the
top of the class. A server that is paginating a resource for HTML
representation is free to define the pages in a way that is convenient for
HTML display, as you point out below.

Best regards, Martin

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



>
> Martin,
>
> Although any resource may have multiple representations, some resources
> may only have one representation. In the case of paging, I think it 
makes

> sense to allow the page contents and breaks to depend on the
> representation initially selected. Different representations will differ
> in their compactness, e.g. one page of Turtle might take 10 pages of
HTML.
>
> Regards,
>
___________________________________________________________________________

>
> Arthur Ryman, PhD, DE
>
> Chief Architect, Project and Portfolio Management
> IBM Software, Rational
> Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
>


_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net














More information about the Oslc-Core mailing list