Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Dec 2013 11:39:27 +1100

On 28 Nov 2013, at 12:30 am, Julian Reschke <[email-masked]> wrote:

> On 2013-11-27 14:18, Michiel B. de Jong wrote:
>> 
>> On 27-Nov-13 13:22, Julian Reschke wrote:
>>> Quoting:
>>> 
>>>>        * Whereas [HTTP, section 10] allows many different status codes,
>>>>          remoteStorage servers SHOULD send the status codes mentioned
>>>>          in section 5 of this Internet Draft, and clients MAY treat any
>>>>          deviation from this as a server malfunction.
>>> 
>>> I still don't understand how that helps. What problem are you solving
>>> here?
>>> 
>> 
>> if we allow servers a choice of all response codes then the client
>> implement code to deal with each one of them. most of that code would
>> never be used in practice, and thus be easily end up being buggy and
>> lead to incompatibility.
> 
> The code to implement unknown codes is trivial. Just treat 2xx as 200, 3xx as 300, 4xx as 400, and 5xx as 500.

More to the point, many status codes are generated somewhere “in between”, whether that be a proxy, a load balancer used by the service, a CDN, a reverse proxy cache, a captive portal, etc. etc. A client that isn’t written to deal with a broad variety of status codes is going to fail when exposed to the real Internet.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Patrick Logan <[email-masked]>
Date: Sun, 1 Dec 2013 19:52:05 -0500

Some redirects instruct the client to use the same method. Others, to use
GET no matter the original method.
 On Nov 27, 2013 5:32 AM, "Julian Reschke" <[email-masked]> wrote:

>  we are solving those three problems (unnecessary work for client
>> implementers, risk of bugs, and risk of incompatibility) by saying
>> exactly which 13 out of 41 (if i counted correctly) status codes we
>> need, to get the job done. the other 28 status codes are useful to some
>> part of the web, but they are useless to our specific problem space, so
>> it's safer to disable them.
>>
>
> I disagree. By unnecessarily creating a profile:
>
> a) you teach people to handle status codes incorrectly,
>
> b) make it impossible to introduce new codes,
>
> c) might make it impossible to use existing libraries,
>
> d) ignore that intermediaries might change messages,
>
> e) make it unnecessarily hard to have a server that supports "your"
> protocol and somebody else's protocol on the same URI.
>
> Best regards, Julian
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 2 Dec 2013 07:25:36 +0100

On 27 November 2013 16:01, Michiel B. de Jong
<[email-masked]>wrote:

> OK, i changed it so that the checklist of status codes to take into
> account is only a summary of what follows from section 10 of rfc2616 and
> section 3.1 of rfc6750:
>
> https://github.com/remotestorage/spec/blob/30f8b53430fa5fce765e94bb8ff991
> 468875356e/draft-dejong-remotestorage-02.txt#L284-L286
>
> so we are no longer sub-setting http. :) thanks a lot for this improvement!
>
> what do people think in general of the endeavor? is anybody interested in
> starting a broader discussion about per-user storage?
>
> in particular, i think:
>
> * the current big industry stakeholders in this space are probably:
> Dropbox, GoogleDrive, iCloud, and SkyDrive.
> * apart from these four, many parties probably have an interest in
> disrupting the per-user storage market, either to neutralize it as a
> business risk, or to create a level basis for entering.
> * remoteStorage is a grassroots project, we are about 1 1/2 people. :) it
> is obvious that we cannot do this without the help from you who are reading
> this.
>
> we hope some of the following parties may be interested in joining this
> effort:
> * ISPs and mobile operators who want to offer more than just bandwidth to
> their users
> * handset manufacturers who want to disrupt the iOS+iCloud /
> Android+GoogleDrive / WindowsPhone+SkyDrive power blocks
> * people who care about open and free technology, also on this new layer.
>
> again, comments very welcome!

Things I'd like to see:

1. Compatibility with other systems doing similar things such as Linked
Data Platform

https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html

2. A modular approach to discovery, such that webfinger is not the *only*
supported discovery mechanism.  It should be perfectly fine to use well
established standards based discovery such as Linked Data.  Forcing a split
eco systems divides efforts imho.

3. A similar modular approach to authentication.  Supporting OAuth is good,
but it would be nice to be able to slot in other standards for verifying
identity.

4. A standardization of the rel and property links used in discovery of
going from a user to storage.  The elements in the spec I could not easily
understand as they were not self documenting.

Consider the work being done by Tim Berners-Lee's lab at MIT, that I
recently posted to your mailing list

http://www.w3.org/ns/pim/space

The principle here is that from a user you can discover preferences.  And
from preferences you can discover what Tim calls "Workspaces".  A works
space is storage endpoint where you can save data, per user, or per app, or
shared.

5. Consider supporting data mashups, so that data can be pulled from more
than one location, and so that apps are able to share data.

As remotestorage is a relatively small community and there are other groups
working on achieving similar goals, I think it would be advantageous to
benefit from each other's work in a modular way.

> cheers,
> Michiel

---

From: "Michiel B. de Jong" <[email-masked]>
Date: Wed, 11 Dec 2013 10:38:49 +0200

> More to the point, many status codes are generated somewhere “in between”, whether that be a proxy, a load balancer used by the service, a CDN, a reverse proxy cache, a captive portal, etc. etc. A…

ok! we fixed this. thanks all for the feedback!

cheers,
Michiel