Re: Inrupt Pod Server

Hi Michiel,

Thanks much for the status report.  I appreciate all the work you and your
team do.  My expression of frustration with the process carries no blame,
these things are inevitable in a project under development.  More
communication wouldn't hurt  though :-).

Could you check this list below and tell me if it describes how IPS will
behave?

PUT & POST with no content-type specified : returns 400 error

PUT & POST with content-type specified : resource is assigned that
content-type regardless of the file extension

PUT & POST with no file extension :  a resource with no file extension is
created

PUT & POST with file extension : that file extension is used regardless of
the content type; under no circumstances does the server create and append
a file extension or alter the content-type based on the file extension

GET on a container with no Accept header or with Accept header set to
text/turtle: returns the Turtle contents of the container listing.  If
there is a metadata file for the container, the response Turtle for the
container will contain any triples in the metadata file.  If the app wants
to see index.html, index.ttl, etc. it is responsible for retrieving them
with a GET on that resource, not on the container itself.

I posted some tests for most of those features in the issues on NSS.

I also wonder about the login flow from the standpoint of solid-cli and
solid-auth-cli command line access.  Jaxon made some changes to solid-cli
with the switch from 4.x to 5.x.  Will those types of changes be needed
with IPS and if so is that something I should look into or will y'all
handle that?

Looking forward to working with IPS!

-- Jeff


On Thu, Sep 19, 2019 at 6:29 AM Michiel de Jong <michiel@unhosted.org>
wrote:

> Hi Jeff,
>
> On Thu, Sep 19, 2019 at 10:20 AM Jeff Zucker <dubzed@gmail.com> wrote:
>
>> I'm not able to attend this week's call but would like to add my thoughts
>> for the discussion of the Inrupt pod server.  I support the idea of
>> switching away from NSS on solid.community at the same time as inrupt.net
>> and making it clear that unless someone picks it up, NSS is no longer
>> maintained.
>>
>
> Great! :)
>
>
>>
>> In advance of major server changes, it would be really helpful if someone
>> with knowledge of the server development could inform app and library
>> developers about the expected time-frame of the changes and exact
>> switch-over time once known.
>>
> It would also help immensely if there could be documentation where we can
>> read about the expected changes before they occur.  These docs should be
>> oriented to app and library developers, not just server implementers and
>> maintainers.  For example, I am thrilled by the pluggable backends (great
>> work!), but in terms of getting my libraries and apps functioning, I care
>> much more about how the REST API and login and authorization flow will
>> behave and how file-naming will work.
>>
>   Those were the things that changed between NSS 4.x and 5.x and caused
>> apps to break at multiple points.  Some advance warning would go a long way
>> to easing the transition.
>>
>
>
>
> Yes. Good news on that front: there should be no API changes and no
> on-disk file format changes. So this transition should hopefully be
> smoother than the previous one, in that respect.
>
>
> I am specifically concerned about the issues filed on NSS 5.x regarding
>> regressions in GET, PUT, and POST with respect to file extensions and
>> content-types.  I'm unsure which of the changes suggested in those issues
>> will be implemented in IPS and I can't really begin to plan without knowing
>> that. Frankly, it's been a discouraging few months since NSS 5 was
>> introduced and I hope for a smoother transition to IPS.
>>
>
> I know, that was an unfortunate confluence of two situations really, first
> in NSS we made a decision to clean up the ResourceMapper which in hindsight
> maybe was better left as it was, because it surfaced a lot of problems and
> the mitigation of those took up a lot of our time, and after that we still
> didn't get to a point where the ResourceMapper was working properly, or
> where we understood its code well enough to safely fix the remaining
> issues. Second, the development of IPS took longer than was originally
> planned, which meant that we were in this limbo state for longer than would
> have been necessary in our original plan.
>
> I know that your team was hit especially hard by this, especially also
> since we couldn't merge Alain's PR, which I personally also feel really
> sorry for.
>
> But the good news is we'll soon be out of the woods and getting very close
> now to setting up a testing server against which we can start to test our
> applications. Also, it should now already be possible to run the IPS code
> on localhost, using the instructions from
> https://github.com/inrupt/pod-server#running-on-localhost-nss-compat-mode.
> There are likely to be some bugs to be uncovered at the beginning, but
> we'll commit to fixing each of them asap as soon as they are reported.
>
> In particular, I'll also test how IPS deals with default content types,
> since I know that was one of the major things you ran into lately with NSS.
>
> Let me know if you have any more questions!
>
>
> Cheers,
> Michiel.
>
> --
>> Jeff Zucker
>>
>