Re: Hydra Telecon Minutes for 2017-06-12

Hi,

Not sure if this is the correct place for this reply. Let me know and I'll
send it to the appropriate place next time. Also I am still playing catch
up with the specs and previous discussions so pardon any mistakes and
misunderstandings.

Using redux patterns within heracles: +1
Redux patterns to store data state and building elements feels inherently
modular and declarative. It would make building requests easy and
intuitive. Only for use cases that are not predefined will the user need to
imperatively define the use case, and things could quickly become unweildy.
Unless there is a strategy for approximating actions based on 'n+1' or more
actions when 'n' isn't available. So two+ actions when one isnt available.

Injecting json-ld into markdown: +0.5
client needs to only display changes happen when the data state changes.
Not sure about the methodology/process.

Instead of the REST API keywords, would the use of a graphql like strategy
instead work better? (with keywords derived from schema.org as Pavlik
mentioned) This way the client doesn't need to know if there are multiple
resources, it only communicates with a single point for its requests.

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


Could we use Observer/Subscriber patterns for client state changes and
server emitted events? If we use redux stores then any changes can be
inherently done in the background and could work independent of
implementation details

New repo setup +1


Sincerely,





*Kartik K AdurWeb/UI Developer, Information Architect, Interaction
DesignerLinkedIn: Kartik Adur Public Profile
<https://www.linkedin.com/pub/kartik-adur/8/b5/894>Personal Website:
kartikadur.wordpress.com <http://kartikadur.wordpress.com>Email:
kartikadur@gmail.com <kartikadur@gmail.com>*

On Tue, Jun 13, 2017 at 12:54 AM, Markus Lanthaler <markus.lanthaler@gmx.net
> wrote:

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