W3C home > Mailing lists > Public > public-webpayments@w3.org > April 2013

Re: GSOC Web Payments Application

From: David I. Lehn <dil@lehn.org>
Date: Fri, 26 Apr 2013 16:04:48 -0400
Message-ID: <CADcbRRM8v3JcK=y0f_MPz7Ndh4yrU9_oFC4Y1dLVEr-QPoPNKQ@mail.gmail.com>
To: Andrei Oprea <andrei.br92@gmail.com>
Cc: Web Payments <public-webpayments@w3.org>
On Fri, Apr 19, 2013 at 11:50 AM, Andrei Oprea <andrei.br92@gmail.com> wrote:
> My name is Andrei Oprea and this is my application for the GSOC Web Payments
> project

Hi, I'm one of the PaySwarm developers also at Digital Bazaar.  Thanks
for sending out your application, here's a few comments.

> Project Description
> ...
> The aim of this project is to create a developer example website based on
> PaySwarm that is capable of selling access to Web Apps. It would have to be
> fully documented, and offer all the steps involved with communicating with
> the PaySwarm API from registration to the actual establishment of a payment
> session and a purchase.
> ...
> The developer website would be a showcase for the ease of use of Web
> Payments, how the process takes place and also see the steps involved if
> they decide to opt in for this technology. The website would offer
> developers a REST API and using cross site HTTP requests (CORS) it would
> offer any web app the possibility to integrate with the PaySwarm solution
> and enable them to sell access to their application. By making it easy to
> issue requests to the developer website the application can validate the
> payments made and confirm or deny access to their content.
> ...

It might be good to better describe what the REST API will be used
for.  Is it API access to a web app marketplace?  Or is it an API that
web apps would use?  I'm a little confused by what will be developed.
There are many possibilities so it would be nice to get a better idea
of what your website will do.

> The scope of the project would include the website, a fully functioning
> environment where people can test out web payments using the PaySwarm
> authority, it would be capable of managing and issuing request to the
> PaySwarm authority on behalf of the Web App enabling them to offer payed
> access to content. It will also include a documentation website, possibly in
> the form of a wiki with detailed steps on how to include and enable this
> solution for your Web App.. The project would be based of the payswarm
> implementation already available on github, it could extend upon it with a
> test suite and documentation on how others can implement this solution on
> their website.
> ...

Are you just going to control the access to web apps with PaySwarm or
write demo web apps that do more with PaySwarm?  The payswarm
wordpress plugin is a good start for the access part and I imagine
there are improvements that could be made.  Your schedule mentions
deciding on features to be implemented.  If you want to suggest a few
now that would be good.  If the schedule goes faster than planned you
could mention some ideas for "stretch" goals.  Maybe get some ideas
from the PaySwarm use cases document:


> Milestones and deliverables schedule
> June/17 - Devise a REST API scheme for the website that would cover all the
> functionality, and interoperability with the PaySwarm authority; Confirm
> with mentor; Validate against other Web Apps maybe with other developers
> June/21 - Begin working on the server, implement basic functionality; Write
> and tests and document the API; Write a dummy Web App that would showcase
> the functionality achieved so far;

Ok, as said earlier, perhaps adding a bit of clarification and
explanation to the Project Description section on what the REST API
will cover would be good.

> June/30 - Submit work for review & mid-term evaluation
> ...

I think you mean July?  Mid-term submission period is July 29 - Aug 2.

> Aug / 1 - Decide on a full set of feature that can be implemented until the
> end of the program
> Aug / 3  - Continue to expand on the functionality set for both the server
> Aug / 20 - Expand the web app to take full advantage of the developer
> website, showcase different uses
> Sep / 1 - Features decided upon should be all available; Begin working on
> the documentation for developers
> Sept / 10 - Tests, code refactoring final changes that can make the deadline
> ...

As said ealier, if you want to include some suggested features in your
application that would would be great.

Thanks and good luck!

Received on Friday, 26 April 2013 20:06:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:23 UTC