Proposal: Server protocol implementation guideline · Issue #214 · unpoly/unpoly · GitHub
Skip to content

Proposal: Server protocol implementation guideline #214

Open

Description

@jwaschkau

Hi,

i think it would be useful to add a guideline for a complete server protocol implementation.

After having problems with redirects, which could be quickly resolved by #213, i could not find documentation regarding the (server side) handling of redirects.

My proposal would be to extend the section of the server protocol with a guide about the cases that have to be considered for a complete server side implementation and are not directly related to the unpoly API.

Activity

  1. adam12 commented on Jul 8, 2021

    @adam12
    Member

    I think a good first step would be adding the redirect strategy Henning shared in #213. I was aware of it as Henning mentioned it to me a little while back, but I hadn't had a chance to look for it in the codebase. Seeing it illustrated as bullet points sets me somewhat at ease for implementation difficulty.

  2. triskweline commented on Jul 9, 2021

    @triskweline
    Contributor

    What are some other things that would have helped you writing your protocol implemention?

    I didn't want to make the redirect persistence a requirement for new integrations, as I found it pretty hard to implement for unpoly-rails.

  3. ivangretsky commented on Jul 9, 2021

    @ivangretsky

    A step-by-step would be perfect)) For those, who are already in the middle of implementing such a protocol the guideline is less useful. They have certain questions, which might not be general to be included in a guideline, but rather should be handled on a case by case basis.

    And we, who only think about starting to think about implementing it for our systems, can't suggest what should be in such a guideline.

  4. jwaschkau commented on Jul 14, 2021

    @jwaschkau
    Author

    What are some other things that would have helped you writing your protocol implemention?

    I didn't want to make the redirect persistence a requirement for new integrations, as I found it pretty hard to implement for unpoly-rails.

    I think a list of headers that need special handling at the server side integration level would make the documentation easier to navigate. A lot of the headers are not directly interesting at the integration level, because they are set by the end-user.

    This list could also be sorted by subjective importance. I think _up_method and form handling should be implemented before redirect persistence.

    Also more code example would be useful. While there are examples for X-Up-Fail-Target, there are none for the important _up_method. Maybe the relevant code sections of the rails-implementation could be linked as a starting point for new integrations.

  5. adam12 commented on Jul 29, 2021

    @adam12
    Member

    I wonder if there's a way we can share a "spec", where we implement an app using our server protocol implementations, and then that spec is run against the app.

    Could we extract the Jasmine tests somehow? and would that be useful?

  6. triskweline commented on Jul 30, 2021

    @triskweline
    Contributor

    The Jasmine specs are just a bunch of static HTML and JS files. Network communication to the server is mocked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions