- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Sun, 2 Nov 2014 12:24:36 -0500
- To: Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSp4DpsTy9x1c91CfLHBpy6p5naA-vxsGmZy-vv7OEAbgA@mail.gmail.com>
Let me narrow the concept to something that would be feasible as a starting point. Whereas the subject line "Web Payment Software Design Patterns" is very broad, my own particular interest is in comparable software design patterns at the the mid-level architecture by which units of entitlement (or obligation) are translocated from one wallet/account to another. Well, I'd also like to see some common software design patterns for wallets, etc etc. I reckon a distributed team of narrowly interested people could assemble an interesting and useful Version 0.1 of a Web Payments Pattern Language. Joseph On Sun, Nov 2, 2014 at 12:00 PM, Jorge Zaccaro <jorgezaccaro@gmail.com> wrote: > +1. Very useful. > > On Sun, Nov 2, 2014 at 11:54 AM, Anders Rundgren < > anders.rundgren.net@gmail.com> wrote: > >> On 2014-11-02 15:45, Joseph Potvin wrote: >> >> Has anyone on this list come across (or co-produced) a high-level >> comparison of the mechanics of transactions within the different payments' >> software systems: debit card, credit card, automated clearing house (incl. >> direct deposit), wire transfer, giro, ripple, blockchain systems? What I >> have in mind are comparable class diagrams and activity (swimlane) diagrams >> for each. >> >> I think what I'm imagining is something like a "Web Payment Software >> Design Patterns" collection. >> >> If a functional systems comparison isn't available presently, does anyone >> else on this list think such a collection would be useful? For my own work, >> such a diagrammatic taxonomy will be useful. If it's not yet started, I'll >> do so. >> >> It seems to me that a comparable set of system-level diagrams in this >> form would be useful towards advancing common undestanding about the >> contibutions and limitations of a W3C specification on web payments. For >> example, in the various activity diagrams, the generic "browser" would >> occupy one of the swimlanes. What would happen within this column, and in >> what order, will need to be the same for each payment method, I reckon. For >> the various class diagrams, there would be a package that expresses the >> scope of the W3C specification, which contains a set of classes with their >> respective sets of attributes. >> >> Useful? Not useful? >> >> >> This would indeed be very useful! >> There's a giant collection of use-cases to go through. >> Who could possibly spend all those cycles? >> >> The WebCrypto++ Demo & Documentation took TWO full months creating plus >> several days of server work but it should probably be considered as >> research since it doesn't exist in the real world (yet). >> >> BTW, it seems awfully hard getting detailed information about Google's >> and Apple's payment systems. >> >> Anders >> >> >> -- >> >> >> Joseph Potvin, M.Phil. MCPM >> Doctoral Candidate, Project Management >> Université du Québec >> >> Chair, OSI Management Education Working Group >> >> Coordinator, The FLOW Syllabus >> http://wiki.opensource.org/bin/Projects/flow-syllabus >> >> The Open Source Initiative >> >> Operations Manager | Gestionnaire des opérations >> The Opman Company | La compagnie Opman >> jpotvin@opman.ca >> Mobile: 819-593-5983 >> >> >> > -- Joseph Potvin Operations Manager | Gestionnaire des opérations The Opman Company | La compagnie Opman jpotvin@opman.ca Mobile: 819-593-5983
Received on Sunday, 2 November 2014 17:25:24 UTC