Hydra Telecon Minutes for 2017-06-12

The minutes from this week's telecon are now available at

   http://www.hydra-cg.com/minutes/2017-06-12/

The full text of the discussion is below, including a link to the audio
transcript.


-------------------------------------------------------------------

Hydra W3C Community Group Telecon Minutes for 2017-06-12

Agenda:
  https://www.w3.org/community/hydra/wiki/Conference_Calls
Topics:
  1. Status update on architectural diagram
  2. Hydra reference client implementation
  3. Strategy for maintaining snippets from Use Cases as datasets 
    and use them in test suite
Resolutions:
  1. Set up a new, empty Heracles.ts repository under the HydraCG 
    organization on GitHub
Chair:
  Markus Lanthaler
Scribe:
  Markus Lanthaler
Present:
  Tomasz Pluskiewicz, Markus Lanthaler, elf Pavlik, Karol 
  Szczepański
Audio:
  http://www.hydra-cg.org/minutes/2017-06-12/audio.mp3


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

Received on Monday, 12 June 2017 19:25:33 UTC