Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC for RDF support in SAFE Client Libs #288

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@nbaksalyar
Copy link
Member

nbaksalyar commented Mar 14, 2019

Markdown rendered version can be found here.

@theWebalyst

This comment has been minimized.

Copy link

theWebalyst commented Mar 14, 2019

Looks very nice @nbaksalyar, great to see 😄

For Solid compatibility we need to support the LDP protocol at some level. As that isn't mentioned in this RFC I take it that this would be provided in safe_app_nodejs or in separate libraries on top of both. I'm curious how this will work. Is there anything that shows how LDP for example might be supported, and for example, how LDP requests would be translated into use of this API. I only know how node-solid-server does this atm, so I'm trying to imagine how we can do the same without a file system like layer (as in storing RDF resources via SAFE NFS).

Going from low level to higher level, I'm imagining something like:

  • LOWEST LEVEL: creation, storage and access to RDF resources as immutable data (using this RDF API)
  • HIGHEST LEVEL: Solid protocols implemented as libraries and/or within safe_app_nodejs (so WebID profiles, LDP containers)

I was thinking there might be more layers than that, but see it might be all that is needed. If so, it begs the question of what happens to SAFE NFS, and if that can sit on top of this API - is that a possibility or the intention? If LDP and NFS were able to work with the same underlying data structures I think that would be cool 😺

If so, it makes me wonder about the efficiency of implementing those higher level functions via RDF based data structures, and what would be in an individual RDF resource stored at an XorURL. For example, might each NFS and/or LDP container be a single RDF resource? I have the same difficulty thinking about these questions with the existing implementations! For example, whether an NFS directory should be a separate resource (e.g. NFS container or RDF resource in this case), and when it should just be an entry in an existing resource (e.g. NFS keys with multiple '/').

In the case of RDF, maybe the question is answered for us. For example, if every LDP container were expected to be a separate resource, but I'm not sure that is mandated. So the question of how to implement this may still remain, with obvious implications for performance (i.e. number of requests, size of RDF resources etc.)

Most/all of the above is outside the scope of this RFC, but I find it helpful to discuss that while trying to understand where this fits and if it has implications for the 'whole'. So I'm trying to see how this RFC fits into the bigger plan, or possible plans. So no need to try and answer all this. If you can point out any wrong thinking on my part, or fill in any areas that would be great. Or if further RFCs are imminent for other areas I'm content to wait. I can't wait to see this in action!

@joshuef

This comment has been minimized.

Copy link
Contributor

joshuef commented Mar 15, 2019

I have to agree about putting the RDF apis in the core. I think we need to rely on this for building out our client side structures etc (NFS/PNS as you touch on), and this makes much more sense than a separate lib or getting into vaults (which if it were wanted later on could be added in, I think).


For Solid compatibility we need to support the LDP protocol at some level.

I think that's largely out of scope for this RFC @theWebalyst . If LDP/SOLID compatibility are desirable, IMO, that should be catered for by an application further up the stack (a modified SOLID server eg).

@theWebalyst

This comment has been minimized.

Copy link

theWebalyst commented Mar 15, 2019

@joshuef sounds good. So I'm hearing:

  • Client Libs: RDF Data support available as this RDF alongside other 'primitives' (such as NFS, WebID, immutable data)

  • SAFE Nodejs AIP: exposing Client Libs pretty much as is still (so not LDP)

  • TBD: separate modular libraries, Maidsafe or third party, providing features such as LDP emulation and closer compatibility with Solid. This is what I now have working at PoC standard for Solid.

At the moment that means: swap this fork of solid-auth-client into your Solid app, and it will work [cough] on SAFE (or on http if you upload to the Web). That module uses the LDP emulation from Safenetworkjs which in turn uses SAFE NFS, so my question is about MaidSafe's plans for NFS.

For example, do you think NFS will remain as is, or might the data structures change to use RDF to represent the file system rather than the keys to Mutable Data?

Any thoughts or guidance in how that might turn out in practice?

Whatever happens, I prefer LDP and NFS to share the same underlying data structures to make it easy for developers to maintain access to the same files and resources, whichever API is used to create and access them.

Sorry this is out of scope for the RFC - we could take it to the forum if there's more to discuss.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.