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

On 19 May 2013, at 16:30, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hi Henry, 
> 
> Henry Story <henry.story@bblfish.net> wrote on 05/18/2013 01:09:02 PM:
> 
> > ... 
> > I was just arguing for POST as a method to append, because my feeling is that
> > our not having PATCH means that peeople want all interactions to 
> > happen in the LDPC, 
> 
> Having just caught up with the mailing list, just back from Rio, I have to say that I'm confused about where you're going with all this. 
> 
> It seems that you are associating inlining with appending and I don't understand that at all. The whole point of being able to inline member resources is to give clients more info than just the list of members from the get-go. 
> 
> Richard rightfully pointed out at the face to face meeting that it would be better to let the client know if that was all there was to know about the resources. 
> 
> I thought it would be an easy addition and it hasn't been. So, you could argue that to save time we should just leave that out for now - it could be added later - but I don't see why we should throw the whole thing out for that matter. 

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. 

It can be done if the the relations are just carefully chosen metadata relations ( relations from an information
resource/document ) such as those the Atom Syntax took care to choose or relations from dublin core.
In that case you can automatically add the relations. But those are metadata relations and certainly not 
the content.  In order to include the content Atom takes a lot of care to quote the content. Erik Wilde has 
himself made that point before. If you do things that way you can certainly automate the inclusion of the
content in order to reduce download time. But that is not what the inlining suggestion is about.

The problem was reducing download time. The proposed solution is not a secure one to use. If you want
a secure one quote the content. So 3. is the safe solution. Anything that goes beyond that is going to 
throw your spec off course.


> 
> > where I think it could be that we can get all our use cases solved 
> > by just linking
> > LDPRs intelligently. I was just hoping that the idea of POSTing to 
> > an LDPR-that-is-not-an-LDPC
> > we could move some of the group members to intuit that they can 
> > solve their problems
> > in a simpler way. 
> 
> Why are you talking about POSTing in a thread on inlined members? 
> 
> > 
> > Henry
> > 
> > > 
> > > cheers,
> > > 
> > > dret.
> > > 
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 
> 
> Regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 

Social Web Architect
http://bblfish.net/