These are chat archives for csarven/ldn

Aug 2016
Sarven Capadisli
Aug 27 2016 19:18
--- ^^ Oh my.. being away 24h and seeing this :)
I'll have to catch up.
@melvincarvalho Before getting into the technical details, let me first say that, we are trying to accommodate some use-cases that are very close to be packaged together here in LDN. In and of itself, the current state of approaches to discover inbox, LDP-like storage and retrieval etc.. are all meant to find a common ground for all players and maximise interplay. So, the balance that we think we've reached so far in the spec is not intended to be "one and only way" (whatever that is and that can vary).
Sarven Capadisli
Aug 27 2016 19:27
Having said that, I myself prefer to stick to the pure FYN approach and require that only from senders, receivers, consumers. However, that's unfortunately not the most optimal grounds for different scenarios. It is perfectly feasible to lower the barrier for receivers because the "publishers" already have some data on the Web. We want to bring in the possibility where they can simply enrich their existing stuff with minimal amount of work. That may or may not be the headers or the content body. Undoubtedly some will think headers are easier and the others the body. This is not the point to debate about IMO. The thing to acknowledge is that, there are different types of roles in the publishing pipeline. For instance, who is the owner of the resource? Is it only the one that gets to describe it in the body or would the headers count as well? There is nothing written in stone about this anywhere. So, we are definitely not trying to make the call on that either.
Amy Guy
Aug 27 2016 19:28
Sarven Capadisli
Aug 27 2016 19:31
rdflib.js and Solid are both equipped to handle link headers, so I don't particularly see why that's complicated. dokieli does it as well with minimal amount of effort. rhiaro also pointed to other examples.
In fact, rdflib.js even triplifies the HTTP headers and puts it in the store out of the box.
Whether one wants to do that or not is a separate issue, but the point is that, it is not something unheard of.
LDP is doing all sorts of stuff in the headers.
So is Solid.
Would it be right to handwave all that because they are not pure FYN / Linked Data (again, whatever that is spec'ed to be)?
There are gray areas here.
Sarven Capadisli
Aug 27 2016 19:39
Having said all that, if we can focus on making LDN work out of the box for some existing implementations and publishing workflows, that'd be a win for all. We are again, literally trying to define a commonality that would work best. We are definitely going to leave out some implementations or philosophies on how to publish. There is no 100% coverage in specs and LDN is certainly not trying to do above and beyond anything else. It is as simple as it gets but not simpler. I hope be can focus on that.
If we can improve the spec to compromise or improve the wording on the stuff, all the better.
Sarven Capadisli
Aug 27 2016 19:47
It is only the discovery part done by senders and consumers that matters. That is, they are the only ones that should be able to find the inbox through the link header in HEAD. Existing receiver implementations don't have to be updated - it is not required for them. Senders and consumers are already 'new' implementations.
So, setting a low bar to say that senders/consumers be able to check HEAD is very reasonable IMO.
Melvin Carvalho
Aug 27 2016 21:20
i understand, i get the tactical reasons, but Im just against the close coupling that forces me to write extra code, which I dont have time for right now
even if i thought it was a good idea, which im unsure of, but i dont have to work out whether or not it's a good idea if im not coding in the space
ive implemented the things i like in LDN and will implement more if there's a benefit, as time allows
but im just working on many projects at the same time and only one person so that leads to prioritization
Melvin Carvalho
Aug 27 2016 21:25
one thing you may want to consider ... if inbox catches on and gets subtypes one day to, typexInbox, typeyInbox, now do we have more headers to deal with
i will be coding inboxes for solid, and an inbox reader, and inboxes for media and financial stuff
they'll be very closely compatible with LDN
but very likely operate at the data layer rather than the protocol layer
so i dont want people to click on my apps and say 'this doesnt work LDN is broken'
but when the test suite is up ill give it a try and see how far it gets