These are chat archives for csarven/ldn

15th
Aug 2016
Bart van Leeuwen
@semanticfire
Aug 15 2016 12:36
Could a LDN Inbox have its inbox elements inlined ?
Melvin Carvalho
@melvincarvalho
Aug 15 2016 12:37
I think so. Could you elaborate on what you mean? You mean the discovery predicate could be put in its own document?
Bart van Leeuwen
@semanticfire
Aug 15 2016 12:38
no if you request the inbox, which in the document uses LDP container to point to its 'messages' could the messages be inlined ( as with LDP Container )
Melvin Carvalho
@melvincarvalho
Aug 15 2016 12:39
we implement this using "globbing" so when I GET Container/* it gives me all the messages. Perhaps not the most elegant solution but very useful! :) This is something that could perhaps benefit from more standardization.
Bart van Leeuwen
@semanticfire
Aug 15 2016 12:50
I'm looking at creating a 'frontend' on top of a JMS Queue with LDN spec
so a RESC interface to read out JMS Queues/Topic
Bart van Leeuwen
@semanticfire
Aug 15 2016 13:34
REST Interface
Amy Guy
@rhiaro
Aug 15 2016 15:44
@semanticfire You can totally return the inbox elements inlined. So long as you return the minimum ldp:contains relation, anything extra you want to include there is up to the implementation
I think I'm probably going to do that with my inbox
Melvin Carvalho
@melvincarvalho
Aug 15 2016 15:44
hmmm
Amy Guy
@rhiaro
Aug 15 2016 15:45
I'm 99% sure this is okay from the LDP perspective, too
Melvin Carvalho
@melvincarvalho
Aug 15 2016 15:46
how will that work in the file system?
Dmitri Zagidulin
@dmitrizagidulin
Aug 15 2016 15:46
the issue is not that it's ok or not from the LDP perspective. It's that it's an unspecified behavior, one way or another
I think one of the to-do items for the LDP Next group is to standardize inlining
so meanwhile, I think it's totally legit
Bart van Leeuwen
@semanticfire
Aug 15 2016 15:59
If a inbox item is gone, a standard '410' would be within the spec of LDP I guess, since JMS Queue/Topic use a destructive read a URI will definitly not persist
Dmitri Zagidulin
@dmitrizagidulin
Aug 15 2016 16:00
what's the question? 410 vs a 404?
Bart van Leeuwen
@semanticfire
Aug 15 2016 16:00
410 -> gone
Amy Guy
@rhiaro
Aug 15 2016 17:14
410 is fine, we don't really specify things like that for individual notfications
(anyone happen to know if LDP uses 410 for resources that are deleted?)
Dmitri Zagidulin
@dmitrizagidulin
Aug 15 2016 17:14
i think it's a soft recommendation
it's hard to enforce something like that, even these days.
Melvin Carvalho
@melvincarvalho
Aug 15 2016 17:14
6.2.3 LDP servers remove the resource identified by the Request-URI in response to a successful HTTP DELETE request. After such a request, a subsequent HTTP GET on the same Request-URI usually results in a 404 (Not found) or 410 (Gone) status code, although HTTP allows others.
Amy Guy
@rhiaro
Aug 15 2016 17:15
@melvincarvalho How it works for fs is an implementation detail. Just as you presumably regenerate the ldp:contains triples whenever something new is created, you can add the resource triples to that file as well
Melvin Carvalho
@melvincarvalho
Aug 15 2016 17:15
i think it's a rather big implementation detail
Sarven Capadisli
@csarven
Aug 15 2016 17:27
@semanticfire Your call as to how you describe your own resource. LDP only requires the ldp:contains so that the notifications can be discovered. If you do anything on top of that, that's all fine and everything but it goes without saying that don't expect arbitrary tooling to 'make sense of' anything else that's part of that resource description.
Bart van Leeuwen
@semanticfire
Aug 15 2016 17:42
ok