Re: Towards Solid Lite

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