Hello!
I’ve been researching how to add, modify, and use custom metadata to all resources in the CommunitySolidServer, but much like one of my other queries here, I am struggling to determine how to break ground.
In essence, I have four requirements:
When a resource is created, is should have “X-Version” metadata added to the “Description Resource” of that file
When the resource is PATCHed with a “X-New-Version” metadata tag, it should increment the description resource metadata “X-Version” by one, and backup the resource in some way
The OPTIONS header should able to return the “X-Version” metadata in a header
If a GET request contains the header “X-Version” it should retrieve that past version of the resource
From what I’ve read, this Version metadata should be stored in a “Description Resource” (DR), but am unsure how to customise what is added to new DRs, how DRs are read, and how DRs can be used to perform modify how queries work to a particular resource. Furthermore, I’m unsure
My question is, where should I create/insert a custom component to achieve this goal? I believe I’ve narrowed down what I need to change to one of the following, but am unsure.
Should I insert a parser into the metadata handler at @id: urn:solid-server:default:MetadataParser?
Should I modify one of the given ResourceStores to do something different with metadata?
Should I swap out some of the OperationHandlers in @id: urn:solid-server:default:OperationHandler?
Should I do some combination of all of the above?
Should I do something I haven’t thought of yet?
I feel like when I start making something it will inevitably be in the wrong spot. Any help working out where to make my incisions would be greatly appreciated.
Mired in Indecision
Kludgy
P.S. A lot of this indecision comes from Components.js being difficult to read and work with for newbies. Documentation is relatively good, but fragmenting it across hundreds of files and folders makes it very difficult to narrow down where to start. Very appreciative of the docs here, otherwise there would be no chance of me getting anywhere with this project.
P.P.S. I could be getting confused between HTTP headers and DRs across the documentation as both seem to be referred to as metadata in some way. Idk though.
Before jumping to customization of the CSS, could you elaborate on why you are wanting to do this?
Note that the default CSS configuration allows you to edit metadata from the client without any custom configurations; see Metadata - Community Solid Server.
In particular, if you are wanting to do versioning - why not, for instance create a new resource for each version and that way you have the full history of resources?
I’m investigating how resource versioning could be used to enhance Solid for a University project.
In terms of the motivation behind it:
In much the same way that users want versioning of files (like in Word, photoshop etc.), I’m looking at whether it could be helpful for developers to have a per-resource versioning system. I’m investigating a simple one, but a more complex git-like one could be beneficial in the future.
Firstly, copying resources repetitively creates a large amount of storage redundancy.
Secondly, the resource history becomes more and more fragmented and unwieldy as versions are created, making it difficult to identify versions with particular properties.
These problems are exacerbated in multi-user environments where the inability to easily track changes others are making to can cause debilitating fragmentation of datasets.
Here’s a summary screenshot from an MSR paper on versioned databases.
An anecdotal example as to why we don’t want to simply “create a new resource for each version” can be seen below. In my Year 10 Book Review assignment, I had to copy paste the file (resource) many times to track versions. However, with a recent Microsoft update to follow Google docs, there is a per-file (resource) versioning history that allows users to collaborate within the same document (resource), and track their personal history with document modifications, without risking this fragmentation.
=>
In essence, the “full history of resources” could still be maintained in a more storage-effective per-resource way that makes it easier to track fragmentary changes, particularly in collaborative environments.
Yes I did see that metadata could be added from the client side, however I am trying to see if I can modify CSS to add this metadata, and thus enable this functionality by default, across a variety of resources.
Perhaps I could use this to create a proof-of-concept though, and implement a decent amount of the logic on the client-side to that end.
and thus enable this functionality by default, across a variety of resources.
However, if you do this it will only work on the server that you deploy. I would encourage doing the metadata maintenance on the client side for now so that your application can work with other deployments as as well.
Ideally your app should work with any spec-compliant Solid server, but that will not be the case here as the way that CSS handles metadata is not part of the spec.
Hmm interesting. Since I’m not planning on deploying this properly or anything (as it is only a proof of concept), I was considering making one custom app for myself that would use the features I implemented. This is so I could investigate whether or not this feature was as helpful as my sales pitch above suggests it could be.
Basically I’m looking at extensions to Solid, so it is perfectly reasonable that what I create on the server is not usable by other applications, as it is a potential extension.
I’ll talk to my supervisor tomorrow about how we should proceed. Honestly I didn’t consider implementing the versioning through client-side metadata maintenance. If this were properly deployed, it would be something supported by CSS, which I guess is why my brain jumped to modifying that to my own custom spec to support it properly.
=> 