Re: Inrupt Pod Server

HI Jeff!

On Thu, Sep 19, 2019 at 5:00 PM Jeff Zucker <dubzed@gmail.com> wrote:

> 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
>

yes


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

yes


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

yes, on the http level (on the fs level the file will have a `$.something`
that encodes its content-type)


>
> 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
>

At the http level, file extensions will always be used literally. At the fs
level, if the extension makes sense then it's used as-is, and if not, a
modifier is appended. For instance if you PUT asdf.txt with content-type
text/plain, then on-disk you'll see just `asdf.txt`. But if you PUT
asdf.txt with content-type text/turtle, then on disk you'll see
`asdf.txt$.ttl`.


>
> GET on a container with no Accept header or with Accept header set to
> text/turtle: returns the Turtle contents of the container listing.
>

yes


>   If there is a metadata file for the container, the response Turtle for
> the container will contain any triples in the metadata file.
>

hm, we haven't implemented that (yet), but if that is how NSS behaves, then
IPS will match that behaviour.


>   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.
>

that's a tricky one, i think the intended behaviour of NSS is:

* if html is preferred over turtle, and index.html exists, it will be served
* otherwise, if index.ttl exists, it will be served
* otherwise, the folder listing will be served

And the goal of IPS is to match NSS's intended behaviour exactly, so that's
what we'll do then! :)


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

ok, will have a look at those!


>
> I also wonder about the login flow from the standpoint of solid-cli and
> solid-auth-cli command line access.
>

Good point!


>   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?
>

Would be good to test that together! I'll also have a go at that.


>
> Looking forward to working with IPS!
>

Likewise! Thanks again for your time and patience here.

Cheers,
Michiel.


>
> -- 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
>>>
>>