-
Notifications
You must be signed in to change notification settings - Fork 1
Findings during solid development
- The Inrupt Client library seemed promising at first but proved rather tedious. The project turned away from them for managing resources and switched to using simple fetches for PATCH requests and query engines for retrieving resources. They did prove useful for managing permissions on resources.
- Not having to import a different engine for each capability but rather a setting on which kind of query to perform when executing the query could be useful.
- A way to specify which links can be traveled would be useful. This is especially the case when building an application since most of the time the developer knows which links should be present.
-
An incremental query engine that accumulates certain sources could be useful. For example at the moment to retrieve all messages, first a messageBox stream must be created and then on every streamresult a stream to retrieve the messages from the messageBox needs to be created. This could be replaced by such an engine that accumulates the messageBoxes as results.
-
An incremental query engine that automatically switches from polling to websockets as soon as the necessary permissions are granted on the sources. For examples, when starting a messages stream, I now need to create a first stream, wait for it to retrieve a result, signalling that the necessary permissions are granted, close that stream and start a new one, so it uses websockets.
It might be useful to standardize the layout of a pod into having some basic folders such as /Documents, /Applications, /temp, /libraries, ... like an operating system has. The watchparty data could then be contained in /Applications/watchparties/ for example. This might go against the idea of having multiple people develop a frontend for the same data however.