Hydra W3C Community Group Telecon Minutes for 2017-10-02

Thanks Karol for scribing. The minutes from this week's telecon are
now available at

   http://www.hydra-cg.com/minutes/2017-10-02/

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


-------------------------------------------------------------------
Hydra W3C Community Group Telecon Minutes for 2017-10-02

Agenda:
  https://www.w3.org/community/hydra/wiki/Conference_Calls#2017-10-02
Topics:
  1. ISSUE-134: Adding already existing resources as collection 
    members
  2. Heracles PR-10 (Action item Markus to combine PR-10 & PR-12)
Resolutions:
  1. Merge Heracles PR-10
Chair:
  Markus Lanthaler
Scribe:
  Karol Szczepański
Present:
  Markus Lanthaler, elf Pavlik, Tomasz Pluskiewicz, Karol 
  Szczepański
Audio:
  http://www.hydra-cg.org/minutes/2017-10-02/audio.mp3


Markus Lanthaler: Meeting: Hydra W3C Community Group Conference 
  Call
elf Pavlik: present+
Karol Szczepański is scribing.

Topic: ISSUE-134: Adding already existing resources as collection members

Markus Lanthaler: 
  https://github.com/HydraCG/Specifications/issues/134
Agenda: Issue #134
Markus Lanthaler: The action items were
Markus Lanthaler: 1) Karol to analyse Jiira/Confluence APIs
Markus Lanthaler: 2) Pavlik to analyse meetup.com and look for 
  another one
Markus Lanthaler: 3) Markus to analyze some Google APIs
Markus Lanthaler: 4) Tomasz to analyze Huddle & Foxycart
Karol Szczepański:  Confluence's APIs is consistent within itself 
  and uses collections as containers, i.e., you can POST entities 
  to a collection [scribe assist by Markus Lanthaler]
Karol Szczepański:  Jiira's API isn't consistent and uses 
  different mechanisms [scribe assist by Markus Lanthaler]
Karol Szczepański:  when I say a container I mean a LDP container 
  [scribe assist by Markus Lanthaler]
Karol Szczepański:  so when adding a resource, it will get it's 
  own URL [scribe assist by Markus Lanthaler]
Karol Szczepański:  and the container itself has a URL as well 
  and can be updated with a PUT e.g. [scribe assist by Markus 
  Lanthaler]
Markus Lanthaler: So, with a playlist, e.g., video entries would 
  be represented as separate playlistitem resources, right
Karol Szczepański:  yes [scribe assist by Markus Lanthaler]
Markus Lanthaler: Did you see any use HTTP LINK or UNLINK?
Karol Szczepański:  no, I haven't [scribe assist by Markus 
  Lanthaler]
elf Pavlik:  I posted my findings on GitHub
  ... Veimo case: like relationship or subscription relationship
  ... requires understanding URI patterns
  ... URI patterns are not provided, thus client needs to have 
  that knowledge
elf Pavlik:  putting or deleting a relationship ammends both 
  collections
elf Pavlik:  in vimeo puts or deletis single resources rather 
  than PATCH a collection
Tomasz Pluskiewicz:  nothings can stop server from modifying 
  other collections/resources
Markus Lanthaler:  if the client wan'ts to update both 
  collections, does it needs to know whether to do it manualty or 
  it can know that server will do that
Tomasz Pluskiewicz:  it would be ackward to take care of all 
  possible side effects or lack of those
Markus Lanthaler:  client probably is not aware of the all 
  resources it is going to affect
Markus Lanthaler:  expressing side effects opens brand new can of 
  worms
elf Pavlik:  modifying dataset or interacting with an interface 
  are two possible approaches
Karol Szczepański:  I think it is not up to Hydra to decide 
  [scribe assist by Markus Lanthaler]
  ... the client should get told what it can do and not care 
  whether it interacts with a dataset or service
  ... it will be a service in either case
  ... and we shouldn't leak the underlying implementation
elf Pavlik:  difference is on how to provide the information of 
  the posible operation i.e. to like something
elf Pavlik:  either with a Like action or something different
Karol Szczepański:  adding semantic actions such as LikeActions 
  should be optional and be on top of PUT, POST etc. [scribe assist 
  by Markus Lanthaler]
  ... the client may not understand those higher level actions 
  LikeActions
Markus Lanthaler: So, what is a POST?
Markus Lanthaler: If the server only advertises a POST, how would 
  the client know what it effects are?
Karol Szczepański:  It wouldn't and it shouldn't execute it.. 
  only GET is a safe operation [scribe assist by Markus Lanthaler]
I've lost you guys
Karol Szczepański:  i worry that if we take actions from 
  schema.org Like etc. we may end up with somethign SOAPish [scribe 
  assist by elf Pavlik]
Tomasz Pluskiewicz:  I don't see issue with the verbs itself, but 
  we don't get RPC because of that [scribe assist by elf Pavlik]
Tomasz Pluskiewicz:  RPC tries to pretend that remote calls are 
  local calls [scribe assist by elf Pavlik]
Karol Szczepański:  the clients know the protocol, the common 
  verbs, errors etc. now you would need to understand more, like 
  those verbs from the vocab [scribe assist by elf Pavlik]
sorry, my connection dropped
back now
Tomasz Pluskiewicz:  you always need some kind of vocab besides 
  minimal HTTP semantics [scribe assist by elf Pavlik]
elf Pavlik:  do we wan't to support different choices i.e. one 
  server uses PUT and another to POST or PATH or other verb for 
  same operation
Karol Szczepański:  IMO user of the API doesn't need to know a 
  vocabulary to perform some actions [scribe assist by elf Pavlik]
Markus Lanthaler:  if there is a developer that implements an 
  HTTP requests as document the server cannot change that 
  implementation
Markus Lanthaler:  other approach is that client can be written 
  so server can change that behavior
elf Pavlik:  various services might need to make some choices on 
  the custom actions
elf Pavlik:  having notion of an action is more extensible
elf Pavlik:  I like the idea of trying to describe the APIs we 
  researched with Hydra [scribe assist by Markus Lanthaler]
Karol Szczepański:  I like the idea of implementing something 
  [scribe assist by Markus Lanthaler]
Markus Lanthaler: I agree
Markus Lanthaler: So, should we continue with implementing the 
  use cases, add new use cases if some are missing etc.
Markus Lanthaler: Or would you like to investigate something else
Karol Szczepański:  Let's continue to implement the existing use 
  cases [scribe assist by Markus Lanthaler]
  ... we can always extend them if necessarz
elf Pavlik:  shall we try to add something to the heracles from 
  the use cases?
Karol Szczepański:  yes, absolutely [scribe assist by Markus 
  Lanthaler]
  ... you should contribute, it's our code not mine

Topic: Heracles PR-10 (Action item Markus to combine PR-10 & PR-12)

Markus Lanthaler: https://github.com/HydraCG/Heracles.ts/pull/10
Tomasz Pluskiewicz:  go ahead, we can always tweak details

PROPOSAL: Merge Heracles PR-10

Markus Lanthaler: +1
Markus Lanthaler:  arrange order of the members so public static 
  goes first, the public, protected and private
elf Pavlik: +1
Karol Szczepański: +1
Tomasz Pluskiewicz: +1

RESOLUTION: Merge Heracles PR-10

elf Pavlik: https://github.com/HydraCG/Heracles.ts/issues/13
elf Pavlik:  pick an issues and let's implement in the heracles
Karol Szczepański:  we have the use cases, just pick one, 
  implement it and send a PR [scribe assist by Markus Lanthaler]

Received on Monday, 2 October 2017 19:11:55 UTC