Re: [apps-discuss] FYI: LINK and UNLINK

On 2013-11-06 18:13, James M Snell wrote:
> On Wed, Nov 6, 2013 at 8:56 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> On 2013-11-06 17:18, James M Snell wrote:
> [snip]
>>>
>>> "All of them" becomes impractical for the reasons I've already given,
>>> particularly without clearly defined, viable, non-theoretical use
>>> cases.
>>
>>
>> I don't understand how "all of them" can be impractical when "two of them"
>> works.
>>
>> Furthermore, how does the (current) lack of a use case affect the
>> practicability?
>>
>
> Not intending to be rude, but I've already answered this... it has to
> do with the amount of a priori knowledge a client needs to unlink or
> update a single link relationship.

I don't see the material difference.

If the client has no reliable way to find out what links are there it'll 
be essentially restricted to edit those that it created itself.

It seems that this is the issue that needs to be addressed.

>>> That said, here's a compromise: Let's expand the uniqueness constraint
>>> to include anchor, hreflang and type. Doing so ought to cover the vast
>>> overwhelming majority of the possibly viable use cases. I can also say
>>> that the server MUST consider the remaining target attributes to be
>>> significant in that, *if* the server chooses to surface those links in
>>> some representable manner, the most recently received values for those
>>> MUST be included. Is that better?
>>
>>
>> I don't think it resolves the issue...
>>
>
> Is it at least a step in the right direction?

Well yes, it includes more parameters, but what I'm mainly concerned 
with parameters that we don't know yet.

Best regards, Julian

Received on Wednesday, 6 November 2013 18:06:05 UTC