Hydra W3C Community Group Telecon
Minutes for 2017-06-12
- Agenda
- https://www.w3.org/community/hydra/wiki/Conference_Calls
- Topics
- Resolutions
- Chair
- Markus Lanthaler
- Scribe
- Markus Lanthaler
- Present
- Tomasz Pluskiewicz, Markus Lanthaler, elf Pavlik, Karol Szczepański
- Audio Log
Markus Lanthaler is scribing.
Topic: Status update on architectural diagram
Markus Lanthaler: let's adjourn this till Ruben joins the call
Topic: Hydra reference client implementation
Markus Lanthaler: this is about how to get the work on the reference client started
PROPOSAL: Set up a new, empty Heracles.ts repository under the HydraCG organization on GitHub
elf Pavlik: +1
Karol Szczepański: +1
Tomasz Pluskiewicz: +0.5
Markus Lanthaler: +1
Markus Lanthaler: Setting it up as an empty repo, not only gives us a clean slate to start with but it also gives everyone a chance to review the PRs to start to fill it. Karol, and Tomasz can obviously use their existing code to create such PRs and we can then discuss them bit by bit.
RESOLUTION: Set up a new, empty Heracles.ts repository under the HydraCG organization on GitHub
Tomasz Pluskiewicz: invested quite some time
... just a personal issue probably
... I'm not entirely happy with what I've done but I think it's the right thing to do
... I'll start to contribute things
Topic: Strategy for maintaining snippets from Use Cases as datasets and use them in test suite
Markus Lanthaler: this was put on the agenda by pavlik
... can you give us some more insights into what you had in mind
elf Pavlik: I wanted to extract all scripts from the markdown files and then embed them with a script into markdown again
... I worked on it but it didn't seem like a very flexible approach
... in Markdown you sometimes just want to highlight stuff and not include a complete block of code
... I was also thinking about using JSON-LD Framing but wanted to discuss it with the group
... also, I noticed we often use different URIs for the same thing in different files
... so we would need to keep them in sync
... the question is do we want to keep the JSON-LD files separate from the Markdown files?
Tomasz Pluskiewicz: I personally would go for separating them
... we could then use a Travis hook to integrate them into the Markdown docs
... so not extracting but inserting from Markdown
... Once we have the snippets as JSON-LD files we could eat our own dogfood and include them in Hydra collections that you could then query with a Hydra client
elf Pavlik: Just to clarify... by extracting I meant the first manual step of splitting these files
... I'd then embed them as you said
Tomasz Pluskiewicz: Right... I think we should make them test cases though with inputs and outputs
... not sure how we can make those snippets test cases
elf Pavlik: Exactly.. for read operations etc. it's relatively simple
... we could have one dataset and work from that
... but with update/delete etc. we would need to change the state of the dataset
... we could do something like Redux does. There's a store that is being updated through actions and reducers
... this allows things like time-travel for debugging etc.
... read operations wouldn't affect the state. Write operations would
... with something like Redux you could have something like a timeslider to debug things
Tomasz Pluskiewicz: I think this is something that Asbjourn had in mind
... to bad he isn't here.. maybe we can put it on the list or discuss it next time
elf Pavlik: More than happy to collaborate. Together we can probably come up with more interesting ideas
Karol Szczepański: Why do we need to use such heavy machinery for this?
... What's the use case?
... I was thinking of these as excercise files for things like unit or integration tests
elf Pavlik: The idea of injecting JSON-LD into Markdown was to keep them clean and consistent
... we don't want to duplicate things
... by externalizing them we can more easily keep them in sync
... but I'm actually not convinced we need to start with a full-blown solution from the get go
Karol Szczepański: I'm concerned about the timeline, the complexity of the Redux pattern etc.
... not sure what the purpose of this approach is
Markus Lanthaler: i think we should have declarative way of defining use cases possibly also to early to understand our requirements [scribe assist by elf Pavlik]
Markus Lanthaler: would like to first better understand how the client looks like and how we are gonna test it
elf Pavlik: I agree, we probably need to work on a few things and see how we want to test it
Markus Lanthaler: how do we move forward with this?
elf Pavlik: thinking about tests... a while ago we removed the Create-/ReplaceOperation etc.
... if we would have a test suite we would see how this would affect clients etc.
... one thing we could look into is to check the state of the dataset before and after an operation
Markus Lanthaler: I think we need to separate between tests between for the server side and the client side
... I think we should split them into two
... server side might be easier.. input is HTTP request.. effect is a change of the dataset
... client side you have a HTTP request & response, an intent and then another HTTP request or an output or something
elf Pavlik: client that is searching a specific operation makes certain assumptions of the expected result
... in one of my experiments I'm working on optimistic updates
... I requery the server after a while and resync the client state
... so maybe it's not always easy to split client and server side
Karol Szczepański: +q
Markus Lanthaler: I still have the same question... how do we move forward with this?
... do we want to try to figure it out now or should we focus on the reference client for now, do tests for just that client and then as we understand it better extract and generalize them
... so that other implementations can reuse them?
... I prefer the latter
Karol Szczepański: Was about to say something similar
... would go with the latter option
elf Pavlik: I agree too
... I'd like to propose we base the test cases on the use cases though
Markus Lanthaler: Completely agree
... we should use those use cases as much as possible
... ok.. I don't think we need a formal resolution on this
... let's just start working on the reference client implementation, write test cases informed by the use cases
... and once we have something we are happy with and that is complete enough we start thinking about how to extract them and make them useful for other implementations as well
... This was the last agenda item for today
elf Pavlik: https://github.com/HydraCG/Specifications/blob/master/drafts/use-cases/6.updating-event.md
... Anything else we should discuss?
Karol Szczepański: +1
Tomasz Pluskiewicz: +q
Karol Szczepański: }q
Karol Szczepański: +q
elf Pavlik: I noticed this use cases has the schema action and other use cases still look for POST, PUT etc.
... Should we make a PR to change that or do we want to discuss this further?
Karol Szczepański: This is due to a lack of clear guidance in the spec
... it will be a good exercise to make this nicer
... and there are various ways to do that
... we should also give clear guidance about that in the spec
Markus Lanthaler: I think it boils down to a PR so that we can have a concrete discussion
... do you want to give it a shot Pavlik?
elf Pavlik: q
elf Pavlik: Sure
Tomasz Pluskiewicz: I think the method is an implementation detail (looking at use case 5) and use link relations as first option
Markus Lanthaler: I agree, keying HTTP operations is an anti-pattern in my opinion
... the spec isn't clear about this (especially after we removed the predefined operations)
elf Pavlik: Agree. We could use schema.org actions or bring back the predefined operations back but that would be weird
Markus Lanthaler: We discussed this before and decided to get rid predefined operations and use Schema.org actions instead (for the latter there probably wasn't a formal decision though)
elf Pavlik: q?
Tomasz Pluskiewicz: What's our take on custom actions/operations? I think we should recommend using primarily Schema.org actions but if there isn't one that matches, we should describe how to create a custom one
elf Pavlik: I'll make a PR with Schema.org actions to get this started
Tomasz Pluskiewicz: I have an additional for the test cases
... What I said regarding input & output on the client is that on the client the result is a request to the server
... the other case is when the client gets something from the server, the client's state should somehow be changed
Markus Lanthaler: For checking the client state may be tricky to not tie that too much to a specific implementation
Tomasz Pluskiewicz: One option may be a test harness but that results in more implementation effort
elf Pavlik: Testing client and server and isolation will be hard
... because client makes assumptions about what will happen on the server
Markus Lanthaler: yes, I thought of this as mocking the server (HTTP responses for certain requests)
... inspecting the client state may be trickier
elf Pavlik: Having some running code will make this easier
Markus Lanthaler: anything else?
... if not, I'll set up the new empty repo right after the call and hope we will see some PRs soon