Re: Towards Solid Lite

On Tue, Oct 31, 2023 at 01:37:47AM +0100, Melvin Carvalho wrote:
>      Implementation-wise, it should be as self contained as possible, with
>      processing happening on the server or client. I suppose something like
>      this
>      could be useful, if it doesn't have too many thorns:
>      [3]https://github.com/jacoscaz/quadstore
> 
>    Just covering this one point for now.** So a big design decision is files
>    vs database.** NSS is files, for example.
>    If going for a database the feature set you describe is quite big.
>    Certainly possible, but I'd be concerned that a lite spec would be losing
>    its "lite" tag if straight off the bat it was offering more than NSS
>    Reason being that I'd like something that could be implemented quite
>    quickly
>    The other option would be a lightweight quadstore or JSON(-LD) library in
>    common usage that has been battle tested.
>    Just some high level thoughts, all is up for discussion
>    When you said it should be no more than a few thousand lines of code, I
>    had to double take.** My hope was for something to start with under
>    1000.** Am I being hopelessly naive?
>    I mean even in CSS if you do a search for communica alone, there are over
>    3800 files.** Yes, files!** Not lines of code.
>    My mental modal would be to cut out 90% of the rarely used items.** And
>    focus on the 10% most valuable, that provides 90% of the common use cases.
>    Then after folks can see what Solid can do, they can get interested in
>    finishing the other 10%.** Or whatever that number is 20% etc.
>    **

It might be that something like semapps or "Big Solid" components provides so
much functionality that you're only writing 1000 lines of glue code, but
libraries tend to be opinionated, can take you off your path, have their own
complexities or unanswered questions.

So there would be a balance between original code and libraries. I would
probably start with the use cases (high level BDD features). Then make some
psuedocode, mock pages, and/or self-contained functional code for those use
cases, then figure out interfaces and basic implementations for auth, data
storage, database, federation, synchronization, and so on. Then see what
interfaces or libraries you can use that are defined by big Solid and others
that can opportunistically/pragmatically be used to fill in big chunks of
functionality, especially those that will help avoid security risks, 
suggest good paths.

I think a lite version could be created where different interests could dig
in over time and add the larger feature set, if the interfaces are created with
that in mind. After all this is the type of functionality linked data is
designed for, and 2023 libraries could do it all in the browser alone.  

However, I don't have enough specific knowledge to say more than that. I used
some of the ealier related libraries (some of which were incredibly ambitious
yet heart-warmingly terrible (-: some of which were science from another
galaxy), I gained some insight on LDP, I know the basics of OIDC &c, but having
the right expert on the team to at least eyeball the work would make a big
difference.  

I am pretty sure people deeply involved in Solid implementations have thoughts
on this.

David

Received on Tuesday, 31 October 2023 01:25:36 UTC