These are chat archives for csarven/ldn

14th
Apr 2017
semanticfire @semanticfire finally found time to look at LDN
Bart van Leeuwen
@semanticfire
Apr 14 2017 11:46
the contents of the notifications themself are freeform right ?
Sarven Capadisli
@csarven
Apr 14 2017 11:51
@semanticfire Absolutely. Entirely depends on applications' needs.
Bart van Leeuwen
@semanticfire
Apr 14 2017 11:52
I'm trying to wrap LDN around a JMS Topic containing updates
but that is tricky since Topic message consumption is a destructive read
can I inline the notification within a inbox fetch ?
Sarven Capadisli
@csarven
Apr 14 2017 11:54
I don't think I understand the question
Bart van Leeuwen
@semanticfire
Apr 14 2017 11:54
If I request ../inbox
the inbox should reference notifications it has, can these notifications also be inlined to the inbox ?
or phrased differently, can I get the inbox and the notification contents in one GET
Sarven Capadisli
@csarven
Apr 14 2017 11:57
I see. That's not defined by LDN. Each notification would need to resolve. If the Inbox also includes the notifications contents in its own description, that's fine. That extra bit is not part of LDN
Bart van Leeuwen
@semanticfire
Apr 14 2017 11:58
I'd like to prevent the extra roundtrip, and solve my destructive read problem in one go
Sarven Capadisli
@csarven
Apr 14 2017 12:00
LDN sets no restriction on Inbox's description other than listing the notification URLs with ldp:contains
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:01
and they must resolve ?
Sarven Capadisli
@csarven
Apr 14 2017 12:01
Yes, but that may be subject to other constraints e.g., access control. Not related to the Inbox URL itself.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:02
I see
Sarven Capadisli
@csarven
Apr 14 2017 12:04
Basically, if your Receiver is capable of resolving the individual notifications, that'd conform. Whether they actually resolve in your setup or not is something else.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:05
I'm more on the consumer side with my implementation
Sarven Capadisli
@csarven
Apr 14 2017 12:07
Yea, normally the Consumer will have to follow-up on the ldp:contains values and fetch
Same thing though. Your implementation may do something extra (like what you describe) but the baseline is what I described.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:08
hmmm
Sarven Capadisli
@csarven
Apr 14 2017 12:08
And I can understand why the extra trip per notification may not be preferable.
Neither is it the case that each notification must be fetched
but rather fetchable.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:09
yeah, and that is actually the problem
Sarven Capadisli
@csarven
Apr 14 2017 12:09
So, if the inbox has other info in there which helps you determine whether to fetch a particular notification or not, that's the application's call.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:09
topics have a destructive read principle
So my initial thought was to have a inbox with only one resource in ldp:contains , and a fixed uri for the notification pointing to a 'get first element from Topic' resource
which technically works ( although with the extra trip ) but the URI for the notification will never change, but does not point to a persistent object
Sarven Capadisli
@csarven
Apr 14 2017 12:15
I wonder if anyone in the WoT WG https://www.w3.org/2016/12/wot-wg-2016.html is aware of LDN's existence. LDN being used in an WoT/IoT app would be cool to see.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:15
could easely be solved with e-Tag to indicate changes
Sarven Capadisli
@csarven
Apr 14 2017 12:15
Yea
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:15
but even then in WoT/IoT you'd like to prevent the round trip
Sarven Capadisli
@csarven
Apr 14 2017 12:16
I was going to suggest that but figured you'd be using that. Last Modified could work too but not as good as etag
I suppose for some class of IoT applications LDN would work out. Otherwise, HTTP is perhaps too heavy
MQTT
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:17
sure, could be interesting for brokers though
Melvin Carvalho
@melvincarvalho
Apr 14 2017 12:18
@semanticfire solid has a very useful feature called globbing you can GET inbox/* and get all the notifications in it
Sarven Capadisli
@csarven
Apr 14 2017 12:20
I think Bart just wants his app to get everything there is to get with a single GET (on the Inbox)
Oh, yea, globbing added the descriptions.. Forgot about that.
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:20
-v
Melvin Carvalho
@melvincarvalho
Apr 14 2017 12:20
globbing will give you the contents, but maybe not some of the meta data ... tho perhaps not best to be too dependent on meta data
Sarven Capadisli
@csarven
Apr 14 2017 12:20
Never really used it
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:21
would that be within the specs /
Melvin Carvalho
@melvincarvalho
Apr 14 2017 12:21
yes
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:21
( of LDN )
Melvin Carvalho
@melvincarvalho
Apr 14 2017 12:21
solid spec, not LDN spec tho
Sarven Capadisli
@csarven
Apr 14 2017 12:22
Bart, what you could do is have the receiver update the Inbox description when the notification changes. IN there include metadata like modified timestamp or whatever, that way.. your application will know whether to make the call to the notification or not after GETing the Inbox
or perhaps however Inbox description is prepared (at runtime) just include the modified info for the notification URL
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:22
that is not the issue, because if the topic empty, I will not have 'contains' in the inbox
my idea was to inline the notification within the inbox, much like ldp containers
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:37
@csarven this is payload as well right: https://www.w3.org/TR/ldn/#notification-announce-annotation
Sarven Capadisli
@csarven
Apr 14 2017 12:39
Yes
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:44
inbox URI's don't have contain any semantics on the resource they represent either right ?
which could point to http://updates.example.com/box/456789 as its inbox
Sarven Capadisli
@csarven
Apr 14 2017 12:45
Right. They are just containers with no knowledge of the resources they point to.
oh
Right, that's also true
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:46
even with request parameters then
Sarven Capadisli
@csarven
Apr 14 2017 12:48
Inbox neither needs to know what points to it or know anything beyond the resource it just points to with ldp:contains
Bart van Leeuwen
@semanticfire
Apr 14 2017 12:48
okay excellent
Sarven Capadisli
@csarven
Apr 14 2017 12:48
The description of the Inbox URL is whatever the Receiver wants
Bart van Leeuwen
@semanticfire
Apr 14 2017 13:13
okay, the only thing I can't resolve the double round trip
Bart van Leeuwen
@semanticfire
Apr 14 2017 13:48
no comment ;)
Sarven Capadisli
@csarven
Apr 14 2017 13:48
I'm not sure if I can help any further on that.
Bart van Leeuwen
@semanticfire
Apr 14 2017 13:49
I was afraid of that :D
I figured a way I can cheat the system, a inbox on a topic only returns ldp:contains if the topic actually contains elements, and points to a static URI which will get the next message from the topic
Bart van Leeuwen
@semanticfire
Apr 14 2017 13:54
my internal code can simply do a get on the static notification, which will wait for the next notification to appear in the topic
( mind U I talk about durable subscribers on topics )
Bart van Leeuwen
@semanticfire
Apr 14 2017 14:04
btw, is there still room for editorial comments ?
Sarven Capadisli
@csarven
Apr 14 2017 14:09
We are probably reaching Rec on April 18 :) So, yes, but I'm not going to like it :) And, atm, I want to keep it to absolute trivial things.
Bart van Leeuwen
@semanticfire
Apr 14 2017 14:29
it is I think
readability and relating the various steps with POST/GET would be easier with conistent URI's
e.g. here I POST ex.com/12345 and the with GET /inbox I see it contains ex.com/12345
where the fetch of the a notification actually contains that what has been POSTed in the sender part