19
edits
Changes
Summer of Code/2015/git backend shaifali (view source)
Revision as of 03:57, 30 March 2015
, 03:57, 30 March 2015no edit summary
* '''Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?'''
* '''Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?'''
'''Brief Explanation''':
'''Brief Explanation''':
The project is aimed to facilitate versioning, cloning, forking, merging, pull requests from Journal, to the end users. Basically Journal database(sugar-datastore) will be rebuild to be a database based on git, so that the features that are needed to improve(versioning, forking etc) can be achieved easily. All the users who practice/learn development using Sugar(turtle blocks)will get benefit from this. For developing git based backend I have two choices:
The project is aimed to facilitate versioning, cloning, forking, merging, pull requests from Journal, to the end users. Basically Journal database(sugar-datastore) will be rebuild to be a database based on git, so that the features that are needed to improve(versioning, forking etc) can be achieved easily. All the users who practice/learn development using Sugar(turtle blocks)will get benefit from this. For developing git based backend I have two choices:
Using some API that provide similar functionality like github provide [git data](https://developer.github.com/v3/git/) but this will create dependency of database on the API and will force to develop the database in the way API wants. Also we have to bear certain limitations if API have, like the git API limits the support of blobs up to 100 megabytes in size[https://developer.github.com/v3/git/blobs/], number of requests per hour are limited(60 requests for unauthenticated requests[https://developer.github.com/v3/#rate-limiting]. So it is better to opt option 2.
Using some API that provide similar functionality like github provide [git data](https://developer.github.com/v3/git/) but this will create dependency of database on the API and will force to develop the database in the way API wants. Also we have to bear certain limitations if API have, like the git API limits the support of blobs up to 100 megabytes in size[https://developer.github.com/v3/git/blobs/], number of requests per hour are limited(60 requests for unauthenticated requests[https://developer.github.com/v3/#rate-limiting]. So it is better to opt option 2.
The impact of this project on end users will be great, as mentioned above in application users will get benefit of versioning, forking, merging, cloning from Journal, their learning experience will improve. Since it will recreate the sugar-datastore, it will impact on Sugar developers too.
The impact of this project on end users will be great, as mentioned above in application users will get benefit of versioning, forking, merging, cloning from Journal, their learning experience will improve. Since it will recreate the sugar-datastore, it will impact on Sugar developers too.
'''Walter Bender:'''
I think there are 2 benefits: a technical one and a user-experience one
The technical benefit is that we are able to leverage a well supported, well understood backend that alleviates the need to keep a custom backend supported
The technical benefit is that we are able to leverage a well supported, well understood backend that alleviates the need to keep a custom backend supported
The user experience benefit is that we can provide mobility of the datastore; versioning of projects; cloning of projects; etc. all of which means it is easier to collaborate and evolve as a learner.
The user experience benefit is that we can provide mobility of the datastore; versioning of projects; cloning of projects; etc. all of which means it is easier to collaborate and evolve as a learner.
'''Quozl`'''
'''Quozl`:'''
The impact may be greater collaboration between sugar users who have not collaborated before.
The impact may be greater collaboration between sugar users who have not collaborated before.