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

út 31. 10. 2023 v 20:50 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
napsal:

>
> On 10/31/23 3:45 PM, Melvin Carvalho wrote:
>
>
>
> út 31. 10. 2023 v 20:41 odesílatel Kingsley Idehen <kidehen@openlinksw.com>
> napsal:
>
>> Hi Melvin,
>>
>> On 10/31/23 8:52 AM, Melvin Carvalho wrote:
>> > Then there are things which a triple store cant do.  Such as saving my
>> > family photos.  Storing a song or playlist.  Uploading a video.
>> >
>> > The web started out by linking documents so it stands to reason that
>> > flavours of solid should inherit this ability, in the general case.
>> >
>> > Does it make sense?
>>
>>
>> A different angle:
>>
>> Triple Stores and Filesytems can exist behind a common abstraction layer
>> provided by HTTP. This kind of abstraction is where Solid comes into
>> play, by making such possible via Single Page Apps deployed via HTML.
>>
>> That's exactly how we use Solid atop our Virtuoso platform (which is a
>> DBMS, WebDAV file server, Middleware combo). Basically, you can work
>> using fileystem interaction patterns while the underlying data is
>> accessible via a number of interfaces and returned in a variety of
>> negotiated formats.
>>
>
> Makes total sense.  That would be a great way to build client side apps.
>
> However a pain point right now is that it is hard to build a server, or
> even find an existing server that is bug free.
>
> A specification to find a minimal subset of Solid to build a working, bug
> free server, that passes tests in the test suite, is the challenge.
>
> The question is which parts of the spec could you take out, and still have
> useful applications.
>
> Not everyone can build something like virtuoso overnight, so what
> properties would create a minimal viable back end.
>
>
> Yes, lite server implementations (that aren't full Virtuoso) are
> important. That said, a good specification should provide a binding layer
> for data stored in a variety of storage systems. This was always what I
> assumed to be ground-zero re Solid i.e., a spec implementable using a
> variety of back-end storage engines.
>

So NSS (node solid server) has been the de-facto reference implementation
for the last decade or so.

It only uses the file system, no database.  Which is consistent with Big
Solid, ie it passes all the tests right now.

Therefore, mandating multiple back ends in Solid Lite would actually be
adding to the spec, not cutting it down, if it was mandatory.  Not saying
that it's wrong or bad, it might be doable anyway.  But just explaining the
parameters.


> --
> Regards,
>
> Kingsley Idehen 
> Founder & CEO
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>               http://kidehen.blogspot.com
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>         : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>
>