Re: Towards Solid Lite

út 31. 10. 2023 v 2:25 odesílatel David Mason <vid_w3c@zooid.org> napsal:

>
> 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.
>

This outline makes sense to me.

What many other projects do these days is to split things into small chunks
around a kernel, then have optional or mandatory extensions (FEPs, PIPs,
etc.)

Perhaps a super minimal core, that could handle very basic use cases.

Then have SLIPs -- Solid Lite Improvement Proposals.

This would all be roughly oriented around the existing test suite.

Most of the SLIPs should be optional and added to the core.  A couple of
SLIPs could become mandatory.

A full recommended subset of the core + SLIPs would be equal to Solid Lite,
with many more addons for those that want them, according to existing tests.

Plus a path to Big Solid which would entail passing all the tests in the
test suite.


>
> David
>
>