These are chat archives for csarven/ldn

2nd
Aug 2016
Melvin Carvalho
@melvincarvalho
Aug 02 2016 11:50
@csarven let me know when is good timing to add this implementation to the spec, It's ready and working now at prototype level, but can do with more cleaning up & testing, so I'd like it to be the best it can be before referencing it. I know there's limited time to get the spec through the WG process so if you have hints on optimal timing, let me know! :)
Im going to write a processor for individual jobs too.
Sarven Capadisli
@csarven
Aug 02 2016 12:54
@melvincarvalho Anytime is fine if you think that it is comformant. We'll have tests sometime this month, so that'll be a bit more proper to check whether the implementations are okay or not. For the spec to go through, we need at least 2 implementations for the required sections in the spec. Right now we are adding the implementations to the list in an informatively. They'll eventually be removed in the final Recommendation, but linked to previous version (CR) which will have the links to the implementation.
Melvin Carvalho
@melvincarvalho
Aug 02 2016 12:55
we have more than two implementations already, right?
Sarven Capadisli
@csarven
Aug 02 2016 12:55
For the moment, we are going with solid-terms:inbox or ldp:inbox (as per spec), but eventually we'll have one and stick to that.
Melvin Carvalho
@melvincarvalho
Aug 02 2016 12:55
it's not hard to have both
coding wise
Sarven Capadisli
@csarven
Aug 02 2016 12:55
Yes, we do, but it has to match the MUSTs in the spec.
So, we need to check carefully at some point.
At the moment, we are leaning on ldp:inbox. I think Solid implementations are open to that possibility if the spec is moves forward. Tim felt that it'd be good to put the discovery property under ldp, but solid could work too.
Melvin Carvalho
@melvincarvalho
Aug 02 2016 12:58
no strong opinion here
Sarven Capadisli
@csarven
Aug 02 2016 12:59
Great to hear that.
We don't have a strong opinion either but feel that ldp will get more mileage / less friction to use
Bart van Leeuwen
@semanticfire
Aug 02 2016 13:06
it just needs some form of 'push' to a client for me then I really would love to implement it
Sarven Capadisli
@csarven
Aug 02 2016 13:07
@semanticfire Push/poll are indeed useful, but the question that's still up in the air is whether that needs to be defined in this spec or simply refer to something that's out there.
Melvin Carvalho
@melvincarvalho
Aug 02 2016 13:08
@semanticfire in solid we use websockets for that
it compliments LDN
but it's not the only way to do it
Sarven Capadisli
@csarven
Aug 02 2016 13:08
We certainly don't want to define our own. Neither do we have the expertise but also it just won't work into 'this' spec. It could be referred to some other note/spec.
Melvin Carvalho
@melvincarvalho
Aug 02 2016 13:08
I have a few apps with push/pull working
Sarven Capadisli
@csarven
Aug 02 2016 13:12
This is not to imply that we don't want to discuss this. IMO, best way forward is to have (sub)section e.g., appendix or under considerations.
Bart van Leeuwen
@semanticfire
Aug 02 2016 13:12
yeah i think not talking about it at all is not what you want
although I see that it is out of scope for the WG
Sarven Capadisli
@csarven
Aug 02 2016 13:13
The 'receiver' is acting as the storage for the notifications. The sender is notifying the receiver. We've just happened to separate the actor 'consumer' as its own. It is not necessarily the final recipient of the notification.
Amy Guy
@rhiaro
Aug 02 2016 13:19
It's not out of scope for the WG - in fact, the SocialWG is getting PubSubHubbub as an editor's draft soon, and ActivityPub (another WG spec) contains it's own subscription mechanism - and in part because of these, it's out of scope for the LDN spec in particular. There are lots of subscription mechanisms. We'd gladly accept help on assembling a list of the most applicable so we can point to them from LDN. But I don't know that we have the expertise to just pick one and say MUST or SHOULD do this. So far several people have suggeseted a subscription mechanism is useful, and everyone has offhandedly suggested something completely different..
Sarven Capadisli
@csarven
Aug 02 2016 13:24
Aside: I would prefer that we don't end up writing tests for the pub/sub section. Not a requirement for LDN receiver/consumer
Bart van Leeuwen
@semanticfire
Aug 02 2016 13:34
is a WG Note a option, "this is how one could do it "
nice discussion topic over beer next week :P
Amy Guy
@rhiaro
Aug 02 2016 13:39
We can certainly have a 'how one could do it' in the LDN spec
If there are several suitable possiblities we can list them
Bart van Leeuwen
@semanticfire
Aug 02 2016 14:17
I even would see a place for LDN over JMS e.g.
Bart van Leeuwen
@semanticfire
Aug 02 2016 15:37
there is no standard way to communicate updates of linked data in enterprise environments
Melvin Carvalho
@melvincarvalho
Aug 02 2016 15:38
SPARQL 1.1? (Update) ?
Bart van Leeuwen
@semanticfire
Aug 02 2016 15:39
that is equal to stating that in enterprise environments all updates are communcated in SQL ??
Melvin Carvalho
@melvincarvalho
Aug 02 2016 15:39
Can be sent via PATCH + mime type application/sparql-update I think ...
Bart van Leeuwen
@semanticfire
Aug 02 2016 15:44
the affordances are clearer with LDN, you announce a update and you get confirmation that the update is recieved, with sparql update if you get a okay, the sender migh assume that the data is inserted
Melvin Carvalho
@melvincarvalho
Aug 02 2016 15:45
true