Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Enhancement] - Restructure how document list is pull from Solid #595

Open
leekahung opened this issue Mar 1, 2024 · 0 comments
Open

[Enhancement] - Restructure how document list is pull from Solid #595

leekahung opened this issue Mar 1, 2024 · 0 comments
Assignees
Labels
discovery Open discussion and exploration of topic on hand enhancement Enhancement of existing features on hold

Comments

@leekahung
Copy link
Contributor

Describe the Current Behavior/Feature:

In its current form, PASS renders the list of documents from Solid in React through the doclist.ttl stored in the Documents container in PASS. As users add documents to their Pod on Solid, the doclist.ttl expands, storing the location of where the uploaded file is stored along with relevant metadata.

In this process, the Upload button in the Add Documents Modal triggers addDocument from src/modal-helpers/DocumentList.js and updates the list on both Solid and React. In React, the list comes in the from of a list of objects called docList (which is also located in DocumentList.js under loadingDocumentList).

While this approach works great to reduce the number of API calls needed to display what document files are in Documents, this document list on Solid works only when users have access to the entire Documents container even if users can get permission for individual files. An alternative approach would be needed in order to allow for file-specific permissions.

Proposed Changes:

There are several approaches I could think of at this moment that's within Solid specifications.

The 1st approach would tackle the issue in a way similar to how PASS had previously implemented document uploads. That being, each file will be stored within a container of the same name along with the metadata (likely in the form of a TTL file) and an ACL file. Each container would be called individually, but we could generate a list that contains specific files other users could have access to when shared. For docList.ttl, we could still use this when the full container is allowed to be shared.

The 2nd approach would tackle the issue by creating new docList.ttl that are user-specific. For example, if we want to share a specific file from the document list, we could generate a new TTL file with the name of the user that is being shared to. For example, if the user wishes to share a document with http://localhost:3000/testpod/profile/card#me, we can create a new ttl file with a name generated using the webId inside Documents. From the client, we can use the parsed form of our document object to generate that list similar to how we create a new list when uploading documents. As for displaying the document list of users who have shared their files, we can have the other user (i.e. testpod) generate a document list using that new document list file instead of docList.ttl, unless the Documents container itself has been shared.

Rationale:

To generate a document list that allows for file-specific permissions.

Possible Drawbacks:

Each approach do have their own drawback. The first approach would be traffic-heavy, with each file needing its own API request from Solid. The folder structure for Documents would also need to be re-worked with utilities functions from the client which would help these containers generate a list of objects similar to what we had now with the existing approach.

For the 2nd approach, while it'll keep the file structure flat inside Documents, would generate a lot of TTL files inside Documents. The name of the new document list ttl files needs to be systematic, utilizing some aspect of the other person's webId, and easy to fetch back like with docList.ttl

@leekahung leekahung added enhancement Enhancement of existing features discovery Open discussion and exploration of topic on hand labels Mar 1, 2024
@timbot1789 timbot1789 self-assigned this Mar 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discovery Open discussion and exploration of topic on hand enhancement Enhancement of existing features on hold
Projects
None yet
Development

No branches or pull requests

2 participants