Website: https://solid.mit.edu/ and https://solidproject.org/ - Repos: https://github.com/solid/ - Forum: https://forum.solidproject.org/
I've managed to pull the glob portion of the GET handler from NSS, I'm allowing users to provide a glob class, which I then replace a couple of prototype functions with ones that will fetch the details from a remote service (like NSS or something else):
https://github.com/o-network/http-rdf-glob/blob/master/src/glob.7.1.3.ts
But the usage of the npm module glob allows more than what the spec says, so I have also made a very simple "globber" that matches the spec and only allows for "*" at the end of the pathname:
https://github.com/o-network/http-rdf-glob/blob/master/src/simple-glob.ts
Above allows to be done by userland, so no need for in NSS any more
You pass a
fetch function, which can either grab locally if being run on the server, or can go and fetch remotely (from NSS)
It uses the list function of a directory, rather than
fs.readdir
My hope is that I will be able to do all this in a cloudflare worker
@fabiancook This may dispatch thousands of GET, and rejected if any of the elements are rejected.
https://github.com/o-network/http-rdf-glob/blob/2452926790418d98ceb88506b92b7f5a8020fce7/src/combine.ts#L45-L51
https://github.com/o-network/http-rdf-glob/blob/2452926790418d98ceb88506b92b7f5a8020fce7/src/combine.ts#L45-L51
If its any error in the 400-499 range it won't error
The same process is being done here: https://github.com/solid/node-solid-server/blob/master/lib/ldp.js#L112
And here is the "GET" https://github.com/solid/node-solid-server/blob/master/lib/ldp-container.js#L27
If the module is being used server side, the requests will be routed directly to the fs-store, rather than doing a remote get request
So yes, you're right, it can do hundreds of GET requests, but is only doing those requests for the resources that matched that were requested by the user, and it will only be hundreds if there were hundreds of matching files.
after quite some time of non-tech distractions, i was refreshing what i know of solid... i figured out some of my difficulties. i don't clearly understand the relation of URIs in the "knowledge graph" rdf space, the separation in turtle files in the solid "filesystem", and HTTP "transport" URLs. i have read the docs several times, and i still don't have it clear. i was trying to read the fetcher sourcecode, but i figured i can also try to ask here =)
I think the best way to think about is to think about nodes in a graph, each node being a turtle resource, each node can reference other nodes by way of a URI, you as a user, or client, interact with nodes, and click through to other nodes using hyperlinks, if you fetch all of these nodes by following all the hyperlinks, you get a graph
@biappi ^
@biappi Yes. The data web of RDF is like the hypertext web of HTML, except nodes are conceptual things insread of parts of a document, and links have well defined semantics. They both use the ‘#’. In both cases the use of a URI
a#b is an invitation to load document a and find out about what it shoses to say about a#b. The document tries to have useful data about a#b and related things those interested in a#b would also be interested in.
The Fetcher fetches each document into the Store. Its a quad store, so it keeps track of which document each (s,p,o) triple came from by in fact storing (s,p,o,document). The store acts as a local cache of part of the data web. So once it has loaded a few documents, then you can query and navigate the RDF graph locally in memory.
You update the data web using UpdateManager.update() which sends a patch to the server, and makes sure the local Store is kept in sync. The UpdateManager can also subscribe to any changes in a document made by others and let each client app do live updates.
Hey everyone, the Toronto event is set for next Monday, May 13th, at 6pm in the evening. Our meetup group is full but there’s still space. Please RSVP at https://www.llbrandlab.com/events/solid-toronto-meetup
@fabiancook @timbl thanks! you gave me the key piece of understanding i was missing. i didn't consider the concept of "document" as being part of the "rdf data web"... i was confused because, ignoring documents, i thought all turtle files could be about about every resource, and of course now i have more understanding of the fourth element of the rdf triples =)
i love that "i am an idiot" feeling when the right piece of knowledge fits the slot and everything makes more sense =)
Hey, just got off call with John and Kelly from @RubenVerborgh connecting us over the POD sync/replication (across different POD providers) and POD encryption (so POD providers can't read data), I have things ready to do this now just need to spearhead it in with somebody who can get me acquainted with codebase nuances... who is interested in SOLID sync & encryption!?
What do you think about caching private data in the localStorage? The way I understand localStorage, it shares it's data with all apps from which have the same domain. This would mean, that if the user has installed two different apps on his pod (or uses them from some kind of appstore), they could access the data from each other regardless of their unique access constraints. Furthermore, they could use the login credentials stored by solid-auth-client even if they weren't given any permission
I've read here, that "Two actors in the Web platform that share an origin are assumed to trust each other and to have the same authority", but I don't really think this applies for solid as giving unique permission control per app is (imo) a key feature of it. That they share the same host doesn't mean that they even know of each other if we think of storing apps on the own pod or using some kind of app store
... that we should host each app on its own (sub) domain. So hosting all the apps I use on my pod is a bad idea then...?
Hi Thomas, you can see the past Solid Events on Germany on https://github.com/solid/information/blob/master/solid-events.md where there is also the link to the organisers
Solid New York organised by Brian Cort is tomorrow! https://www.meetup.com/NextWeb-NYC/
That design is forced on us by the browser Same Origin Policy