Property that indicates how much disk space is used in POD

[megoth]

As an extension of https://github.com/solid/vocab/issues/29 and an solution available for https://github.com/solid/node-solid-server/issues/918, we might need a property that denotes the total size of all files in a given POD. Do we want to introduce this property, and what should it be named?

Building on https://github.com/solid/vocab/pull/35 I propose the property solid:totalFilesSize.

An example (that could be used in serverSide.ttl):

</> solid:totalFilesSize "13000"^unit:Byte

[RubenVerborgh]

I don't think serverSide.ttl is the right place for this.

What we need instead are virtual resources, that correspond to such dynamic things. For v5, we might just hard-code a route.

[megoth]

Do we have any examples of virtual resources already? Wouldn't that approximate the functionality of an API?

[RubenVerborgh]

Do we have any examples of virtual resources already?

Not in v5.

Wouldn't that approximate the functionality of an API?

Well, everything is an API obviously, but yes 🙂

[megoth]

Well, everything is an API obviously, but yes 🙂

Yeah, I should be should be more specific 😛 I was thinking of a specific endpoint like /account/diskSize that would return how much disk space is used for a specific webId. But I think this was mentioned earlier, and it has some weaknesses/problems (that I cannot remember now...).

[RubenVerborgh]

I was thinking of a specific endpoint like /account/diskSize

I'd say /account, with a bit more data than that.

[akuckartz]

Can't we have /account/diskSize and /account ?

[RubenVerborgh]

We could, but why? A single-triple document is overkill, particularly if we consider that we cannot hardcode this URL but have to link to it.

[csarven]

Can't we have /account/diskSize and /account ?

Literally, no. In the first case "account" is a directory, in the second it is a file :)

Edit: Yes, I've heard of URI opaqueness :)

I like the singe resource idea revealing some stats.

[megoth]

Ok, so it seems we'll go for the virtual resource idea on this? Is there some recommended documentation that I can read up on to understand that concept in context of the Solid server?

[megoth]

(I realize my proposal should've been in https://github.com/solid/node-solid-server/issues/918, but I thought it better to continue this thread)

[MasterJames]

Does not the http enable this already? Here is a javascript example. http://voidcanvas.com/how-to-get-the-memory-size-byte-kb-mb-of-an-image-or-other-files-without-loading-it-by-javascriptajax/

[RubenVerborgh]

Does not the http enable this already?

Browser-side JavaScript can tell you the size of a representation of a resource. I cannot tell you the size of your data pod.

[megoth]

After discussing this with @RubenVerborgh a bit more, we've decided to create an endpoint that returns linked data about the account at /account.

For this I'll use a term that indicates the total file size of the POD.

In case people have strong feelings on this, I'll introduce some other names that could indicate the total file size used (and there are probably variants of this these I haven't thought of):

• solid:diskSpaceUsed
• solid:diskUsage
• solid:podSize
• solid:podUsage
• solid:storageUsage
• solid:totalFilesSize
• solid:totalPodUsage
• solid:totalPodSize
• solid:totalStorageUsage

Please let me know what people think makes most sense.

Edit 1: Just added solid:totalFilesSize so that people can see the various suggestions easily up against each other (I'll add more if there are other suggestions as well). Edit 2: Added more suggestions

[csarven]

solid:diskUsage like linux du? Sounds good to me.

[csarven]

Maybe it should be added to http://www.w3.org/ns/posix/stat eg. take note of posix:size

[megoth]

Maybe it should be added to http://www.w3.org/ns/posix/stat eg. take note of posix:size

That is an interesting idea; what is the process to suggest additions/changes to that vocabulary? (In terms of time, I think I'll add it to the solid-vocabulary first, but might be interesting to get it into stat if others have the need as well)

[kjetilk]

I'm kinda against "disk", since it points at spinning disks, and it is not necessarily spinning disks anywhere anymore soonish. :-) That's why I proposed :nvmQuota, which is more descriptive of what it is on a better abstraction layer "non-volatile memory", but that was too hard again...

About stat, that seems quite intimately tied to POSIX stat which is about file or file system, and not a tree of files... So, I'm not sure I would add to that.

How about solid:totalStorageUsage?

[RubenVerborgh]

Storage is great. Also drive, pod.

[justinwb]

What about solid:totalPodUsage?

[kjetilk]

or solid:totalPodSize? :-)

[csarven]

@megoth Rough consensus :)

@kjetilk @justinwb is "total" necessary? Would it be anything but total: 'storageUsage', 'podUsage' 'podSize'?

@kjetilk Yea, I wasn't too sold on posix/stat ns myself. Seemed closest.

storageUsage works for me. Sorta reflects pim:storage (emphasis on 'storage')

Something something about naming things is hard something :)

[justinwb]

@csarven I agree that "total" seems superfluous there - fine by me to simplify. Better readability 👍

[megoth]

I've updated the list in https://github.com/solid/vocab/issues/37#issuecomment-439050430.

Personally I'm leaning toward solid:storageUsage or solid:podUsage, mostly the latter; I like the idea of getting the word POD more semented into our terminology.

[csarven]

@megoth Perhaps :) Personal Data Store (PDS) https://en.wikipedia.org/wiki/Personal_data_service is more commonly used than "POD". I favour 'storage' because it is a bit more agnostic than 'pod'.

[kjetilk]

Yeah, was in brainstorm mode. :-)

Actually, I don't like "Personal Data Store" as a generic term, unless it does just that, but I think we need to very soon will have something that supports streaming data without necessarily storing anything. But in this case, it is specifically about storage, so yeah, I can go for solid:storageUsage.

[MasterJames]

fileCount(baseDir='t'), fileList(baseDir='/') totalSize(baseDir='/'), baseDir could be a file too, which could be known links or references for count and list. I guess a list can be asked for it's length but is smaller for transport and a more complete comprehensive API. Single file in count is pointless unless there are multiple redundant links or versions tracked. Single file in list would validate or maybe return links and references etc. otherwise just totalSize would allow single files and not just directories as an argument. Wait maybe 'single file' is an array/list of files with wildcards and they have search ability to so for example totalSize for all '*.png'

[csarven]

I think the unit of the storageUsage value should be specified - at least in property's comment. Was it discussed somewhere or are we assuming bytes?

[kjetilk]

This can be closed, right?

[megoth]

It is still not implemented as https://github.com/solid/node-solid-server/issues/918 is still a work in progress IIRC. It is connected to https://github.com/solid/node-solid-server/pull/1060, which has work in https://github.com/solid/node-solid-server/tree/feature/quota-ui that should be followed up.

I must admit I had completely forgotten about this, and we should discuss how we want to make sure that the work is completed (ie if I or @jaxoncreed should complete it). But that can be done outside of this issue, as we landed on solid:storageUsage and that is already merged into the vocab.