2015-03-23, 20:16
Name: Cole
Summary: Database For Retroplayer
How will I achieve this: I will use SQLAlchemy+Protobuffs+ZeroMQ to create a language agnostic API for Retroplayer data
What will the project focus on:
Extensibility. Most programmers very much dislike SQL and do whatever they can to stay away from it. By abstracting the database away from the developer I will create an easily extensible interface. The API will be defined by the protobuffs definition. If you change the protobuff definition, or add a new message the database will change to meet the protobuff specification. The protobuffs message defines the database structure.
Benefits:
A backend such as this will allow other developers to focus on the core logic of Retroplayer without having to worry about the database backend. This segmentation and tool chain also has the built-in ability to operate across TCP, with any of the numerous languages that are supported by both protobuffs and zeroMQ. When successful it also has the ability to serve as a model for improvements to the Kodi persistent storage model.
This backend will have the ability to build a database from scratch. No user or dev interaction with the database will be needed.
Goals:
1. Discuss implementation and design.
2. Draft initial message design and relationship model, write protobuff messages.
3. Write SQLAlchemy MetaClasses
4. Testing/Documentation
5. Write query API
6. More testing/documentation, will have a goal of 100% code coverage.
7. Implement security best practices and optimize speed.
What does it touch in Kodi: Nothing, it will provide an API for persistent storage agnostic of database implementation.
Possible mentors: garbear
I have professional experience with both SQLAlchemy and ZeroMQ. I know the pitfalls and gotchas of both APIs. I designed an API that used a message system that is similar to protobuffs. It leveraged both SQLAlchemy and ZeroMQ to create a persistent storage solution used for a distributed system of robots at a major US research facility. I feel that this model, after implemented successfully in retroplayer can replace the current persistent data model in Kodi. Becuase of the implementation's ability to create new tables and relationships based upon a simple message definition it will be easy for add-ons to also use the database.
While not in my realm of expertise, I can also design the user-facing portions of the library as well. I do, however, want my focus to be on implementing a rock solid well tested backend. I see this as a start to being an active developer of a project I have used for many years.
Summary: Database For Retroplayer
How will I achieve this: I will use SQLAlchemy+Protobuffs+ZeroMQ to create a language agnostic API for Retroplayer data
What will the project focus on:
Extensibility. Most programmers very much dislike SQL and do whatever they can to stay away from it. By abstracting the database away from the developer I will create an easily extensible interface. The API will be defined by the protobuffs definition. If you change the protobuff definition, or add a new message the database will change to meet the protobuff specification. The protobuffs message defines the database structure.
Benefits:
A backend such as this will allow other developers to focus on the core logic of Retroplayer without having to worry about the database backend. This segmentation and tool chain also has the built-in ability to operate across TCP, with any of the numerous languages that are supported by both protobuffs and zeroMQ. When successful it also has the ability to serve as a model for improvements to the Kodi persistent storage model.
This backend will have the ability to build a database from scratch. No user or dev interaction with the database will be needed.
Goals:
1. Discuss implementation and design.
2. Draft initial message design and relationship model, write protobuff messages.
3. Write SQLAlchemy MetaClasses
4. Testing/Documentation
5. Write query API
6. More testing/documentation, will have a goal of 100% code coverage.
7. Implement security best practices and optimize speed.
What does it touch in Kodi: Nothing, it will provide an API for persistent storage agnostic of database implementation.
Possible mentors: garbear
I have professional experience with both SQLAlchemy and ZeroMQ. I know the pitfalls and gotchas of both APIs. I designed an API that used a message system that is similar to protobuffs. It leveraged both SQLAlchemy and ZeroMQ to create a persistent storage solution used for a distributed system of robots at a major US research facility. I feel that this model, after implemented successfully in retroplayer can replace the current persistent data model in Kodi. Becuase of the implementation's ability to create new tables and relationships based upon a simple message definition it will be easy for add-ons to also use the database.
While not in my realm of expertise, I can also design the user-facing portions of the library as well. I do, however, want my focus to be on implementing a rock solid well tested backend. I see this as a start to being an active developer of a project I have used for many years.
