Re: files or database for solid pods [Was: Towards Solid Lite]

út 31. 10. 2023 v 16:26 odesílatel Sjoerd van Groning <sjoerd@muze.nl>
napsal:

> Op 31/10/2023 om 14:31 schreef David Mason:
> > On Tue, Oct 31, 2023 at 01:52:50PM +0100, Melvin Carvalho wrote:
> >>     You've described a use case that requires merging, and given a
> beautiful
> >>     example of how a triple store makes merging cheaper.** I agree.
> >>     However making merging cheaper comes at a cost.
> >>     Now I need a whole data base infrastructure of use cases that dont
> require
> >>     merging.** Such as storing a document.** Saving a note.** Creating a
> >>     profile, and so on.
>
> That deviated quickly from a simpler spec (Solid Lite) to new features.
> Please don't kidnap threads this way. Lite means cutting stuff out.
>
> For the current spec I think a filesystem is a very logical and not
> complex solution, making implementation a lot easier.
>
> The whole DB versus FS discussion brings back the blog from Ruben:
> https://solidlabresearch.github.io/WhatsInAPod/


There are certainly arguments for and against filesystem vs database.

Filesystem is great for small amounts of data, "it just works" and has
decades of tooling.  Multiple mime types, and existing global deployment.

Databases get good when data is larger, allow scaling updates, indexes
queries as built in.  Harder to do large files.

An idea could be to for both to live side by side, but when we've
experienced that in solid before (e.g. webid-tls vs oidc) there is a danger
that one starts to want to eat the other, rather than live side by side.

In the 100s of meetings ive had with timbl, on solid, and on social linked
data, I'm fairly sure timbl considers the file system part of the web.  So
we probably should respect that.

I lean towards just saying start off with the file system for a lite spec,
as it's no extra deployment cost.  But I grately sympathize with the
possibility to add a database as data scales.  I would agree that this
could be an optional add on, or SLIP (Solid Lite Improvement Protocol)
fairly early on, but not a MUST.


>
>
> In the end requiring every small bit of data a separate access list
> would be technically challenging (but not impossible ofcourse) and very
> difficult for a consent list UX.
>

What about a simple rule such as, public get to read, owner gets to write.

I think that allows an upgrade path to full WACL, and should pass the test
suite.


>
> Here are some thoughts we had about it:
>
> https://www.linkedin.com/pulse/solid-do-we-need-little-helpers-sjoerd-van-groning/


Solid helper, nice idea, plays well with different types of pods, and
bridge to existing data


>
>
> https://www.linkedin.com/pulse/solid-different-views-linked-data-sjoerd-van-groning/


Transformers changing data from one format to another is indeed an
important problem.


>
>
> I am very interested in feedback on our thoughts about it. We prefer a
> filesystem. Much easier (especially for Solid Lite).
>

Great feedback, thank you.  IMHO all good pragmatic suggestions that can
get us to an MVP quickly.


>
> Kind regards,
> Sjoerd
>
> --
> Sjoerd van Groning
> Muze
>
> T. 053 - 4308177 | 06 - 41265099
> I. www.muze.nl | www.simplyedit.io | www.pdsinterop.org
> E. sjoerd@muze.nl
>
>
>
>