[alto] SSE final touches

[Y. Richard Yang]

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

[Jan Seedorf]

Hi Richard,

Post by Y. Richard Yang
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

Post by Y. Richard Yang
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.
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
https://www.ietf.org/mailman/listinfo/alto

[Y. Richard Yang]

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

Post by Jan Seedorf
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
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.
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
https://www.ietf.org/mailman/listinfo/alto

[Vijay K. Gurbani]

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,

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!

- vijay
--
Vijay K. Gurbani / ***@nokia.com
Network Data Science, Nokia Networks
Calendar: http://goo.gl/x3Ogq

[Jan Seedorf]

Hi Richard,

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

 - Jan

Post by Y. Richard Yang
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
Hi Richard,

Post by Y. Richard Yang
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

Post by Y. Richard Yang
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.
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
https://www.ietf.org/mailman/listinfo/alto
<https://www.ietf.org/mailman/listinfo/alto>

_______________________________________________
alto mailing list
https://www.ietf.org/mailman/listinfo/alto
<https://www.ietf.org/mailman/listinfo/alto>
--
--
 =====================================
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>        |
 =====================================

[Y. Richard Yang]

Jan, Vijay,

Thanks a lot for the guidance!

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

Richard

Post by Jan Seedorf
Hi Richard,
great, thanks, as chair I support that decision in the light of finishing
some charter items soon.
- Jan
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

Post by Jan Seedorf
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
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.
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
https://www.ietf.org/mailman/listinfo/alto

--
--
=====================================
| Professor of Computer Science |
| http://www.cs.yale.edu/~yry/ |
=====================================
--

Richard