Re: base paradigm

my comments inline...

On Mon, Jan 13, 2014 at 1:46 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> On 01/03/2014 12:36 AM, David Nicol wrote:
> > there is discussion of "the base technology" --- how about going one
> > level more abstract? Can we get a consensus on "message passing" as
> > the base paradigm?  Or do we, rather, favor remote procedure calls?
> > Or something else? Is there a difference? Am I raving?  Thank you
>
> In general, this is the base paradigm we've been using thus far for the
> PaySwarm spec stack:
>
> 1. Assume the Web exists and is available to avoid re-inventing the
>    wheel or uneven focus on corner cases.
>
*** You mean "The Web" (as in linked HTTP) or "The Internet" (as in TCP/IP,
UDP, etc.)? I think the Web is the way to go, but we need to be prepared to
support protocols other than HTTP (CoAP, XMPP, etc.) where the method set
(transfer verbs) are limited or quite different and cases where the
low-level protocols is not TCP/IP.


> 2. Stay compliant with the Architecture of the WWW, because it scales
>    really well to billions of people.
>


> 3. Use URLs to denote "things" such as financial accounts, identities,
>    products, services, etc.
>
*** I think you're going to run into significant dissonance w/ #6 here. BTW
- I assume you mean URIs and not URLs. If you're thinking URLs, then I
would say that runs counter to the guidance in [1] and that document should
be the guide when it comes to the use of URLs/URIs in services. If you're
committed to REST, I'd re-write this to say "Use identifiers in the
ontology to denote actions such as financial transactions, etc, etc." The
attempt to add "Actions" to Schema.org[0] is an acknowledgement (IMO) of
this trend to focus on actions over things.


> 4. Use messages that are capable of expressing Linked Data, because
>    extensibility and the freedom to innovate is important.
>
*** If you mean messages and in media types (JSON-API, HAL, Siren, etc.)
then I think you're on to a good thing. If you mean "objects" expressed in
XML or JSON, I think you're heading for scaling problems. Again, this
relates to #6 below.

5. Build on top of well-understood protocols, such as HTTP.
>
*** I think it is very important to NOT cleave too closely to a single
transfer protocol. WebSockets, XMPP, CoAP, and other protocols are likely
to play a significant role in many parts of the payment chain in the
future. Assuming things like "GET" and "POST" in interaction design are
going to make for confusion when attempting to use the ontology over other
protocols.


> 6. REST is a good design paradigm for Web-based protocols, use it
>    until something better shows up.
>
*** As already stated on this thread REST is about transferring *state*.
REST focuses on the actions, not the "things." REST offers ways to describe
actions using hypermedia. OO-style designs leave this out (and assume the
client and the human writing the client carry this information in their
heads by using the procotol implicitly).  Adopting action-oriented REST
hypermedia is an excellent way to go, but may run counter to items #3 and
#4 above.

7. Don't be afraid to suggest that the previous 6 items are broken in
>    some way.
>
*** yep, took your advice (grin).

[0] http://schema.org/docs/full.html
[1] http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-00