Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notifications? Or queuing mechanism? #21

Closed
gklyne opened this issue Jul 11, 2016 · 17 comments

Comments

Projects
None yet
6 participants
@gklyne
Copy link

commented Jul 11, 2016

On a quick scan of the spec, I'm not seeing any way for consumers too receive notifications asynchronously which, in my perspective, would be the whole point of "notification"s.

What I do see is a queueing mechanism that allows one party to queue information packets, and another to retrieve them when they're ready.

Maybe this is fine and useful, but if so I guess I'd suggest the spec may be misnamed.

@csarven

This comment has been minimized.

Copy link
Member

commented Jul 13, 2016

Are you looking for a way the sender and the consumer can communicate directly? The spec does have the condition that the receiver stores the notification as an intermediary. The notifications in this case are not ephemeral but resources with their own URIs.

@gklyne

This comment has been minimized.

Copy link
Author

commented Jul 14, 2016

Not necessarily direct communication. I'm quite comfortable with the idea that a notification is a distinct resource with its own URI.

As I read the current spec, the consumer is required to poll (GET) to see if a notification is available. I'm not seeing any way that the consumer can be notified (sic) without such polling (e.g. by subscribing a URI to be prodded when a new notification becomes available).

(I could understand that such a mechanism is out of scope for the design/requirements you have in mind - but, from my experience, that's what I expect "notification" to mean.)

@csarven

This comment has been minimized.

Copy link
Member

commented Jul 14, 2016

The spec doesn't prevent consumers and receivers from communicating in real-time but doesn't describe how right now. This is possibly out of scope, but which of the various real-time communication mechanisms would you implement?

@gklyne

This comment has been minimized.

Copy link
Author

commented Jul 15, 2016

I'd probably go for something like the consumer offering a URI that the receiver can post to when a notification arrives. E.g. something along the lines of http://www.w3.org/TR/prov-aq/#provenance-pingback. But that's just a possible mechanism, and the specifics aren't so important (though preferably incrementally easy to implement within the context of an LDP stack).

@csarven

This comment has been minimized.

Copy link
Member

commented Jul 28, 2016

In your scenario, it sounds like the consumer is also a receiver, and the receiver is also a sender.

What we don't have is a way for any receivers to request things from senders. This is a subscription mechanism, and there are several existing options. I think it's out of scope for LDN to add anything new, but it certainly doesn't prevent people from implementing the subscription mechanism they prefer in receivers and senders.

Having said that, we're open to proposals for subscription mechanisms which you 1) prefer and why 2) have implemented or plan to implement before the end of Candidate Recommendation. If there's consensus around something like this, it's possible we can recommend one for use with LDN in particular.

It's also worth noting that other specs in the SocialWG include subscription mechanisms: ActivityPub and PubSubHubbub.

@stain

This comment has been minimized.

Copy link

commented Jul 28, 2016

Agree on a "ping" mechanism like PROV ping, possibly where you register to be ping with a kind of "You have new mail" (but not what) - that way you don't need to ping for every notification and can rate-limit.

@mklyne

This comment has been minimized.

Copy link

commented Jul 30, 2016

Per your terminology, it may well be that what I'm suggesting is a consumer that performs technical interactions similar to a receiver. But I'm not sure that's of itself useful focus. (I found the terms "consumer" and "receiver" a bit arbitrary, but, hey, you gotta call them something.)

My understanding was that the "consumer" is a component that is a final recipient of a notification, and a "receiver" is a hub-like component that provides a common point of contact between originator and consumer.

My suggestion (or expectation) was that the pubsub-style of interaction be propagated all the way to the consumer, so that a consumer that is able to maintain a listening point is not forced to poll.

If your intent is that other Solid mechanisms be used to provide this kind of capability, then I think it could help to explain this in the spec: the name "notification" raises (for me) the expectation that it can be delivered asynchronously (i.e. non-polled).

@gklyne

This comment has been minimized.

Copy link
Author

commented Jul 30, 2016

Oops... that last comment was me, accidentally posted using wrong Github account.

@csarven

This comment has been minimized.

Copy link
Member

commented Aug 3, 2016

Right. In terms of who gets to store and view the notification, it is the receiver and the consumer respectively. I agree that one way of looking at notifications is stuff that comes to me. We are just more explicit about who that is by splitting them up: one that stores the notification, and the one that makes a request to view it. If a notification can be accessed but a consumer doesn't request it, is it not a notification? If a tree falls in a forest...

I acknowledge the usefulness of a subscription mechanism, but 1) it is slightly out of LDN's scope and 2) there are existing approaches out there we can point to - without mandating a single one for conformance. Perhaps the middle ground is:

Proposal: To improve the spec, add an informative section (maybe an Appendix?) about some possible ways to do a subscription mechanism as well as pointers to relevant specs.

How does that sound?

@gklyne

This comment has been minimized.

Copy link
Author

commented Aug 5, 2016

If async notification is out of scope for LDN, then I think it would be good for this to be clear right up front, preferably in the abstract, so that people like me looking for such a mechanism don't have to read the whole spec.

As for adding an informative section as you suggest - I'm easy about that, but I'm not sure if it would be worth the effort.

@akuckartz

This comment has been minimized.

Copy link

commented Aug 5, 2016

Such an informative can potentially be the foundation for more.

@akuckartz

This comment has been minimized.

Copy link

commented Aug 5, 2016

That should have been "informative section".

(The mobile GitHub interface does not allow editing comments after they have been submitted :-(

@gklyne

This comment has been minimized.

Copy link
Author

commented Aug 6, 2016

(re informative section...) Indeed, but if you're aiming this for some kind of standards track then it also becomes something else for people to disagree about. If async notifications is out of scope for this, then say so, and leave discussion of options to a separate document. My 2c.

@csarven

This comment has been minimized.

Copy link
Member

commented Aug 24, 2016

Added an initial non-normative section: https://linkedresearch.org/ldn/#subscribing-to-notifications . Is something like that acceptable for this issue?

@gklyne

This comment has been minimized.

Copy link
Author

commented Aug 24, 2016

I think the informative section is fine.

But...

Now I find myself asking: what is it about a "notification" that distinguishes it from an arbitrary message. I just skimmed every occurrence of "notification" and mentally replaced it with "message", and I don't think it makes any fundamental difference to the spec. Why are you calling them "notifications"?

Related, I think the abstract could be a little more informative about the intended scope of use of this protocol. E.g.

Linked Data Notifications is a protocol to facilitate exchanging notification messages between applications which serve as senders, receivers and/or consumers of RDF data. Notification messages are intended to be used to provide information about resources managed using LDP protocols, such as status changes or other events related to the resource. The protocol described here is entirely synchronous, and does not provide for asynchronous delivery of notification messages.

This is just an example of what I think you're intending to specify here. My point here is to be more explicit so that it is easier for someone to figure out if the protocol might be relevant to something they are trying to do with linked data.

csarven added a commit that referenced this issue Sep 1, 2016

@csarven

This comment has been minimized.

Copy link
Member

commented Sep 1, 2016

Updated the Abstract. What do you think?

We tried to emphasise that the receiver is the focal point with regard to receipt of notifications. Technically the receiver can have notifications delivered to it asynchronously. The consumer is an additional piece, so that notifications can be reused.

information about resources managed using LDP protocols

This isn't true - notifications can be about any resources, regardless of how they are managed.

@gklyne

This comment has been minimized.

Copy link
Author

commented Sep 2, 2016

I think that's more informative.

(I hadn't grasped the bit about the main focus being on receivers, and consumers being "extras".)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.