Subject: [alto] SSE final touches

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 17 Mar 2018 13:07:38 +0000

Dear all,

As we finalizing all aspects of SSE, two issues need some discussions.
Quick updates, without delaying the progress, can produce a higher quality
 document.

1. It is the notification-of-remove response issue. It is already being
started in an earlier thread. Any opinions will be appreciated.

2. One next step we are considering is the support of multipart update. The
sever may send a multipart message consisting of multiple objects say A, B,
... each of which is a top level JSON object. Both merge patch and JSON
patch support only a single object and hence cannot apply if we want
incremental updates. Hence, if we want incremental updates, we need to
provide an individual client-id for each part of a multipart content.

Another alternative design is that we require that each potential multipart
service also allow individual transmissions. This is the write up in the
current version. Any quick discussions will be great.

See you in London.
Richard
-- 
Richard

---

From: Jan Seedorf <[email-masked]>
Date: Sun, 18 Mar 2018 10:55:27 +0100

Hi Richard,

>
> 2. One next step we are considering is the support of multipart 
> update. The sever may send a multipart message consisting of multiple 
> objects say A, B, ... each of which is a top level JSON object.. Both 
> merge patch and JSON patch support only a single object and hence 
> cannot apply if we want incremental updates. Hence, if we want 
> incremental updates, we need to provide an individual client-id for 
> each part of a multipart content.

what is the motivation behind the multipart update? Sure it is a nice 
feature, but as you know, we are trying to finalise SSE asap. So we 
would only like to introduce new feature at this time if they are 
absolutely needed.

  - Jan

On 17.03.18 14:07, Y. Richard Yang wrote:
> Quick updates, without delaying the progress, can produce a higher 
> quality  document.
>
> 1. It is the notification-of-remove response issue. It is already 
> being started in an earlier thread. Any opinions will be appreciated.
>
>
> Another alternative design is that we require that each potential 
> multipart service also allow individual transmissions. This is the 
> write up in the current version. Any quick discussions will be great.
>
> See you in London.
> Richard
> -- 
> Richard
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 18 Mar 2018 13:16:57 -0400

Jan,

The authors had a very extensive discussion again. We have decided to
support only single-object ALTO resources, and leave multipart, which can
be a nice feature to support composition without the need of accumulating
all objects into a single object, as future work. We edited a few sentences
to make clear.

Thanks a lot for the guidance!
Richard

On Sun, Mar 18, 2018 at 5:55 AM, Jan Seedorf <[email-masked]> wrote:

> Hi Richard,
>
>
> 2. One next step we are considering is the support of multipart update.
> The sever may send a multipart message consisting of multiple objects say
> A, B, ... each of which is a top level JSON object.. Both merge patch and
> JSON patch support only a single object and hence cannot apply if we want
> feature, but as you know, we are trying to finalise SSE asap. So we would
> only like to introduce new feature at this time if they are absolutely
> needed.
>
>  - Jan
>
> multipart service also allow individual transmissions. This is the write up
> in the current version. Any quick discussions will be great.
>
> See you in London.
> Richard
> --
> Richard
>
>
> alto mailing [email-masked]://www.ietf.org/mailman/listinfo/alto
>
>
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 18 Mar 2018 22:38:02 -0500

I think that is a wise decision.  One can continue adding bits and
pieces to the protocol ad infinitum.  Best to get what we have out
and let the implementations and needs then guide us towards whether
multipart update will serve a substantive community.  If it does,
I suspect that willing hands will rise to scratch that particular
itch.

>From my understanding, nothing is preventing the update of multiple
objects, just that with the current constructs, they have to be done
serially instead of in parallel.

Cheers,

On 03/18/2018 12:16 PM, Y. Richard Yang wrote:
> support only single-object ALTO resources, and leave multipart, which
> can be a nice feature to support composition without the need of
> accumulating all objects into a single object, as future work. We edited
> a few sentences to make clear.
> 

- vijay
--
Vijay K. Gurbani / [email-masked]
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

---

From: Jan Seedorf <[email-masked]>
Date: Mon, 19 Mar 2018 11:46:39 +0100

Hi Richard,

great, thanks, as chair I support that decision in the light of 
finishing some charter items soon.

  - Jan

On 18.03.18 18:16, Y. Richard Yang wrote:
> accumulating all objects into a single object, as future work. We 
> edited a few sentences to make clear.
>
> On Sun, Mar 18, 2018 at 5:55 AM, Jan Seedorf <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Richard,
>
>>
>>     update. The sever may send a multipart message consisting of
>>     multiple objects say A, B, ... each of which is a top level JSON
>>     object.. Both merge patch and JSON patch support only a single
>>     object and hence cannot apply if we want incremental updates.
>>     Hence, if we want incremental updates, we need to provide an
>>     individual client-id for each part of a multipart content.
>
>     what is the motivation behind the multipart update? Sure it is a
>     nice feature, but as you know, we are trying to finalise SSE asap.
>     So we would only like to introduce new feature at this time if
>     they are absolutely needed.
>
>      - Jan
>
>
>>     As we finalizing all aspects of SSE, two issues need some
>>     discussions. Quick updates, without delaying the progress, can
>>     produce a higher quality  document.
>>
>>     multipart service also allow individual transmissions. This is
>>     the write up in the current version. Any quick discussions will
>>     be great.
>>
>>     See you in London.
>>     Richard
>>     -- 
>>     Richard
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/alto>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/alto>
>
>
>
>
> -- 
> -- 
> | Y. Richard Yang <[email-masked] <mailto:[email-masked]>>   |
> | http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>        |

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 19 Mar 2018 12:08:39 +0000

Jan, Vijay,

Some on this mailing list sent me some notes and it looks that they have
good thinking on SSE. We can engage later.

Richard

On Mon, Mar 19, 2018 at 10:47 AM Jan Seedorf <[email-masked]> wrote:

> Hi Richard,
>
> great, thanks, as chair I support that decision in the light of finishing
> some charter items soon.
>
>  - Jan
>
Richard