Re: ISSUE-58: the simple solution to inlined membership - ISSUE-45

Henry Story <henry.story@bblfish.net> wrote on 05/19/2013 12:49:06 PM:
> ...
> 
> The point is that inlining other resources is merging information 
> from different graphs. That requires either
> 
>  1. the server to know that the graphs that are members are all 
consistent
>  2. the client to know that when it POSTs something it is POSTing 
> something that is compatible with the content
>    of all the members
>  3. the inlined content to be carefully quoted
> 
> Neither of 1 or 2 those is something that can be done easily without
> creating problems. Mechanically it can be
> done easily but you'll very quickly end up with inconsistent graphs.
> It is not easy for either the server to do 
> it correctly or the  client to do it correctly. Especially as the 
> client will have difficulty having a full overview 
> of the all the members. 

As it has been pointed out before inlining is optional and servers that 
don't know how to do it just shouldn't.
I can see how this might be challenging in a vanilla implementation where 
the server merely stores triples blindly to regurgitate later but in the 
case of an application specific server it is not.

Take for instance the case of a bug tracker in which I have a container 
listing all the bugs related to a given project. Inlining can be done 
without problems. If it can't then the server has a serious bug somewhere.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group