Re: Towards Solid Lite

pá 10. 11. 2023 v 12:15 odesílatel Pete Edwards <pete.edwards@inrupt.com>
napsal:

> David
>
> But I wanted to ask the community, rather than everyone creating their own
>> front end applications, which may create corner cases, is there any
>> reference
>> Solid client?  It's nice to have something hands on. As well, is there a
>> subset, or a way to manage expected fails for the existing Karate tests
>> that
>> can be easily run against new implementations?
>
>
> There is a mechanism in the Karate-based test suite that could help you
> run a subset of tests for a Solid Lite implementation. When you use the
> docker image it comes with a test manifest which runs all available tests
> against the Solid Protocol spec. However, you can mount your own test
> manifest into the image to change this behaviour. This would allow you to
> create a smaller manifest which only runs the tests you were interested in.
> Since it would be loading the current solid spec it would show you which
> requirements were untested. However, it could also reference a different
> version of the spec as long as the requirements were still annotated with
> RDFa so that the Conformance Test Harness can load the spec & manifest in
> order to build a list of tests to run. Then the report would only show
> results for requirements defined in that version of the spec.
> *
> https://github.com/solid-contrib/specification-tests/blob/main/README.md#creating-a-script-for-a-ci-workflow
> - how to run tests with your own manifest/spec
> *
> https://github.com/solid-contrib/specification-tests/blob/main/README.md#test-manifest
> - more about the test manifest
> *
> https://github.com/solid-contrib/specification-tests/blob/main/README.md#annotations
> - how to create your own list of requirements in Turtle instead of relying
> on a spec with RDFa annotations, this would allow you to extract a subset
> of requirements for testing even before they are gathered into their own
> spec
>

Thanks alot for the brilliant Test Suite, Pete!

I've started my journey on trying to pass the tests, unsure what the best
route is.

So I just picked something, and started with CRUD tests.

At the moment I have got up to 2 of 9.

Quite fun to try and increase coverage.  100% would be nice if possible.

Any suggestions for plan of attack welcome!


>
> Pete
>
>
> On Fri, 10 Nov 2023 at 02:59, Jesus Noland <jesusnoland@gmail.com> wrote:
>
>> Would you be willing to share a link to the Python implementation?
>>
>> On Mon, Nov 6, 2023 at 7:20 AM Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>>
>>>
>>> po 6. 11. 2023 v 15:52 odesílatel David Mason <vid_w3c@zooid.org>
>>> napsal:
>>>
>>>>
>>>> Hi Aron, nice to meet you.
>>>>
>>>> On Sun, Oct 29, 2023 at 01:07:38AM +0800, Aron Homberg wrote:
>>>> >    I was also thinking about implementing the spec myself aka. "If
>>>> you can
>>>> >    build it, you truly understood it"..., but given the size of of
>>>> the spec,
>>>> >    it seems like quite alot of work. Having a defined set of features
>>>> for an
>>>> >    MVP-style Solid server would be much appreciated.
>>>> >    The tech-set I'm thinking about is Astro + TypeScript + React for
>>>> the
>>>> >    frontend, and the backend implemented with Node.js + TypeScript in
>>>> a more
>>>> >    functional and "serverless" architecture (lamba functions,
>>>> basically, and
>>>> >    as horizontally scalable as possible, even though this is probably
>>>> not
>>>> >    necessary atm.; just as a fancy design goal). The impl. I imagine
>>>> would be
>>>> >    modern, less complex and able to be one-click deployed & hosted on
>>>> Vercel,
>>>> >    Netlify & co. with a single click (fork on Github, depoy via cloud
>>>> based
>>>> >    CI/CD), and for free (for personal use at least).
>>>> >    I think something like a Lite spec + most simple impl. could maybe
>>>> also
>>>> >    attract a wider developer community...
>>>> >    However, I'd like to suggest that such a Lite spec should better
>>>> not
>>>> >    derail from the main spec too much but rather just pick the
>>>> important
>>>> >    parts (if thats even feasible), if it is intended to be compatible
>>>> with
>>>> >    existing implementations. "Derailing" would probably create chaos
>>>> and
>>>> >    effectively become a spec fork, as soon as the diff is too large.
>>>> "Lite"
>>>> >    implementations would then become non-interoperable with NSS, CSS
>>>> etc.
>>>> >    The test suite is pretty amazing, I must say. If defining the
>>>> "Lite"
>>>> >    subset of the spec would start with marking the necessary
>>>> paragraphs with
>>>> >    a tag and simply providing only the relevant subset of the tests
>>>> as a
>>>> >    "lite" testsuite subset, it would be a pretty straight-forward and
>>>> >    pragamatic approach that I'm sure, would help developers like me,
>>>> >    navigating the most important parts.
>>>>
>>>> I thought Melvin did a pretty good job of condensing it.
>>>>
>>>
>>> Thank you, though it's only a week old and v0.0.1
>>>
>>>
>>>>
>>>> I am inching toward a backburner/corner of desk implementation. So I
>>>> wouldn't
>>>> expect fast progress. But there might be some useful overlap. I would
>>>> take the
>>>> lead from Melvin's Javascript implementation as much as possible.
>>>>
>>>
>>> FWIW I made a full implementation in JS in a day.
>>>
>>> Someone approached me (not on this list) and did a full implementation
>>> in python over the weekend.
>>>
>>> He is now already building his first solid app
>>>
>>>>
>>>>
>>>> My focus is very specificallly high level specification/test driven,
>>>> and adding
>>>> functionality to a core through interfaces, so that the results are
>>>> highly
>>>> focused, reusable and not bound to any environment (serverless is an
>>>> planned
>>>> target; right now it supports local and Azure storage, my current work
>>>> is
>>>> re-using test scripts for load tests).
>>>>
>>>> In this approach, implementations are bundled with BDD "steppers,"
>>>> which can be
>>>> mapped to specification documents for accessible tests and
>>>> functionality.
>>>> I work for a government, and am trying to create a way forward that is
>>>> responsibly transparent, educational even (on the principle of full and
>>>> informed consent), and does not bind to any environment (local, cloud,
>>>> etc)..
>>>>
>>>> Interesting in this approach is that it's well suited to "AI" team
>>>> members; a
>>>> person writes the spec, which creates a basis for the AI to write BDD
>>>> tests,
>>>> code, unit tests, all of which people and AI can refine in a test based
>>>> iterative workflow that results in versioned specifications, high level
>>>> tests,
>>>> and environment neutral code with their own unit tests. It still
>>>> requires
>>>> expertise to specify and evaluate the work, but contemporary AI can be
>>>> leveraged in a responsible way that builds out the offering.
>>>>
>>>> Still, there is a lot to work out in even a Solid lite approach,
>>>> especially
>>>> strict data definition.
>>>>
>>>> I don't want to clog the list with side-ideas, so will write you
>>>> separately.
>>>>
>>>
>>> It will be more productive to work in other areas until it gets mature,
>>> and to v0.1.  I'm cautiously optimistic that it can reach v1.0 no later
>>> than Big Solid 1.0 becomes a REC.
>>>
>>> While too early for the vast majority of this list, if there are
>>> intrepid implementers that want to work in a constructive way we can
>>> continue discussion off-list.
>>>
>>>>
>>>>
>>>> But I wanted to ask the community, rather than everyone creating their
>>>> own
>>>> front end applications, which may create corner cases, is there any
>>>> reference
>>>> Solid client?  It's nice to have something hands on. As well, is there a
>>>> subset, or a way to manage expected fails for the existing Karate tests
>>>> that
>>>> can be easily run against new implementations?
>>>>
>>>> David
>>>>
>>>>
>>>>
>>
>> --
>> Jesús Noland
>>
>
> This e-mail, and any attachments thereto, is intended only for use by the
> addressee(s) named herein and may contain legally privileged, confidential
> and/or proprietary information. If you are not the intended recipient of
> this e-mail (or the person responsible for delivering this document to the
> intended recipient), please do not disseminate, distribute, print or copy
> this e-mail, or any attachment thereto. If you have received this e-mail in
> error, please respond to the individual sending the message, and
> permanently delete the email.