Outreachy/2015/December to March: Difference between revisions

Fix bullet points syntax
(Fix header formatting and mentor name.)
(Fix bullet points syntax)
Line 59: Line 59:
There are different use cases:
There are different use cases:


- Alice wants to use [https://github.com/leplatrem/routina Routina], an application that stores its data inside a Kinto instance. As such, Routina needs a way to discover where it should store its data, and send the requests to this server;
* Alice wants to use [https://github.com/leplatrem/routina Routina], an application that stores its data inside a Kinto instance. As such, Routina needs a way to discover where it should store its data, and send the requests to this server;
 
* Bob and Alice want to collaborate on a set of data (think about a shared expense webapp). There should be a way for Alice to host everything and grant access to Bob to her data. The webapp should be able to use the correct server.
- Bob and Alice want to collaborate on a set of data (think about a shared expense webapp). There should be a way for Alice to host everything and grant access to Bob to her data. The webapp should be able to use the correct server.


Here are the different steps that could allow these scenarios:
Here are the different steps that could allow these scenarios:


- At the moment they authenticate, the client detects the email address used, and relies on the domain part to do a [https://tools.ietf.org/html/rfc7033 Web Finger] request on the domain (*) and for the specified user.
* At the moment they authenticate, the client detects the email address used, and relies on the domain part to do a [https://tools.ietf.org/html/rfc7033 Web Finger] request on the domain (*) and for the specified user.
 
* In case the identified server doesn't support WebFinger, it uses a central repository to lookup where the Kinto server is located.
- In case the identified server doesn't support WebFinger, it uses a central repository to lookup where the Kinto server is located.
* Once the Kinto server located, all requests should be issued against this server.
 
- Once the Kinto server located, all requests should be issued against this server.


(*) It is also possible to use the same mechanism to discover the FxA endpoints. But as FxA isn't a federated protocol, users from one FxA realm would need to be accepted explicitely by the Kinto server, in its configuration.
(*) It is also possible to use the same mechanism to discover the FxA endpoints. But as FxA isn't a federated protocol, users from one FxA realm would need to be accepted explicitely by the Kinto server, in its configuration.
Line 75: Line 72:
In terms of code changes, here is what it looks like (rough step by step):
In terms of code changes, here is what it looks like (rough step by step):


- Update the [https://github.com/kinto/kinto.js Kinto.js client] to find the server location. It should first rely on WebFinger;
* Update the [https://github.com/kinto/kinto.js Kinto.js client] to find the server location. It should first rely on WebFinger;
 
* Create a central repository of server locations. This could be contained in the FxA profile server or in a central Kinto collection;
- Create a central repository of server locations. This could be contained in the FxA profile server or in a central Kinto collection;
* Update the Kinto.js client to fall-back to this central repository in case no Web Finger exists;
 
* Investigate on ways to store this information directly in the web browser. It could also be configurable by the JavaScript client (with
- Update the Kinto.js client to fall-back to this central repository in case no Web Finger exists;
 
- Investigate on ways to store this information directly in the web browser. It could also be configurable by the JavaScript client (with
an UX that looks like [https://remotestorage.io/ what Remote Storage proposes]).
an UX that looks like [https://remotestorage.io/ what Remote Storage proposes]).
* Work on the first user experience: how can client learn they can chose which server to use?
* Ship it!


- Work on the first user experience: how can client learn they can chose which server to use?
To get started on Kinto:
 
- Ship it!
 
That's all (it's already a big list, even if I was afraid to have a project to small to length for 3 months, I now believe it's just the
right amount of time)
 
To get started on Input:
* Read [https://kinto.readthedocs.org the kinto documentation], especially tutorials
* Read [https://kinto.readthedocs.org the kinto documentation], especially tutorials
* Join us! Work through our [http://kinto.readthedocs.org/en/latest/contributing.html#communication-channels communication channels] chapter which includes joining the [https://mail.mozilla.org/listinfo/kinto Kinto development mailing list] and joining the #storage channel on irc.mozilla.org
* Join us! Work through our [http://kinto.readthedocs.org/en/latest/contributing.html#communication-channels communication channels] chapter which includes joining the [https://mail.mozilla.org/listinfo/kinto Kinto development mailing list] and joining the #storage channel on irc.mozilla.org
Confirmed users
120

edits