Archive:Dev:File and Content Interfaces - Revision history

Karellen: Karellen moved page Dev:File and Content Interfaces to Archive:Dev:File and Content Interfaces without leaving a redirect: Outdated

2020-07-20T23:57:19Z

Karellen moved page Dev:File and Content Interfaces to Archive:Dev:File and Content Interfaces without leaving a redirect: Outdated

← Older revision		Revision as of 23:57, 20 July 2020
(No difference)

Karellen at 23:57, 20 July 2020

2020-07-20T23:57:00Z

← Older revision		Revision as of 23:57, 20 July 2020
Line 1:		Line 1:
	~~{{mininav\|[[Development]]}}~~		As part of the present Database Schema 4.0a database redesign, I decided to examine more of a "top down" view of the world, and from there extrapolate what the database should look like. What would the ideal interfaces between the file and content management parts of XBMC, and the rest of the application, look like? There are some primary requirements for these interfaces:

	As part of the present [[Database Schema 4.0a\|database redesign]], I decided to examine more of a "top down" view of the world, and from there extrapolate what the database should look like. What would the ideal interfaces between the file and content management parts of XBMC, and the rest of the application, look like? There are some primary requirements for these interfaces:

	* They should hide the implementation; e.g., clients (other parts of the code) shouldn't need to know a database is involved.		* They should hide the implementation; e.g., clients (other parts of the code) shouldn't need to know a database is involved.
Line 29:		Line 27:
	Well-known collections may have well-known IDs, or just be fetched by name (since the parent and the name will be unique, implying that top-level names are also unique).		Well-known collections may have well-known IDs, or just be fetched by name (since the parent and the name will be unique, implying that top-level names are also unique).

	Collections do not necessarily need to live in a database table. For now, they're just an interface to something that can contain content and other collections. A virtual "Genre" collection could exist whose children are collections that are names of genres, which contain content belonging to that genre, generated by (if the present database schema were used) queries to the genre, genrelinkmovie, and movie tables. Also, each current ~~[[plugins\|~~plugin]] can be represented as a collection object, probably a child of a well-known "Plug-ins" top-level node. A content item belongs to one primary collection, and may also belong to multiple secondary collections (it can also be helpful to think of them as classifications).		Collections do not necessarily need to live in a database table. For now, they're just an interface to something that can contain content and other collections. A virtual "Genre" collection could exist whose children are collections that are names of genres, which contain content belonging to that genre, generated by (if the present database schema were used) queries to the genre, genrelinkmovie, and movie tables. Also, each current plugin can be represented as a collection object, probably a child of a well-known "Plug-ins" top-level node. A content item belongs to one primary collection, and may also belong to multiple secondary collections (it can also be helpful to think of them as classifications).

	A content item (recall this particular document is slanted towards video content) has the following interface; first we describe images, which are linked from content:		A content item (recall this particular document is slanted towards video content) has the following interface; first we describe images, which are linked from content:
Line 68:		Line 66:
	}		}

	These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.		These somewhat reflect the tables in the Database Schema 4.0a page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.

	Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in Kodi context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).		Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in Kodi context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).

	There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking~~\|stacked]]~~ content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)		There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some File Stacking content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)

	The file interface:		The file interface:
Line 100:		Line 98:
	*** This document is incomplete; further work to come.		*** This document is incomplete; further work to come.

	[[Category:Development]]		[[Category:Development-Archived]]

NedBot: Bot: Automated text replacement (- XBMC + Kodi )

2015-05-04T08:32:05Z

Bot: Automated text replacement (- XBMC + Kodi )

← Older revision		Revision as of 08:32, 4 May 2015
Line 70:		Line 70:
	These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.		These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.

	Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in ~~XBMC~~ context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).		Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in Kodi context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).

	There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking\|stacked]] content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)		There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking\|stacked]] content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)

NedBot: Robot: Substituting template: Name

2014-06-05T20:20:45Z

Robot: Substituting template: Name

← Older revision		Revision as of 20:20, 5 June 2014
Line 70:		Line 70:
	These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.		These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.

	Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in ~~{{name}}~~ context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).		Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in XBMC context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).

	There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking\|stacked]] content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)		There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking\|stacked]] content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)

NedBot: Bot: Automated text replacement (- XBMC + {{name}} )

2014-06-05T01:02:06Z

Bot: Automated text replacement (- XBMC + {{name}} )

← Older revision		Revision as of 01:02, 5 June 2014
Line 70:		Line 70:
	These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.		These somewhat reflect the tables in the [[Database Schema 4.0a]] page, but not entirely. For example, refreshing content data from online – Content::Refresh – would need some information to know where to re-fetch the data from, but that information (onlineSource in the content table) is not part of the public API. The object stores the URL of the original scrape, and uses it when a refresh is requested.

	Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in ~~XBMC~~ context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).		Types were genericized. It's safe to assume that ‘string' means ‘CStdString' in {{name}} context, and date could be internally a integer Unix-style time representation, exposed as a date object. Furthermore, the idea is that the object either exposes accessors and mutators (date Content::GetDate() const, etc.) or a general accessor that returns a const struct (perhaps a CVideoInfoTag).

	There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking\|stacked]] content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)		There is also no mention of a file. In the general sense, a file is a seekable "stream"; content items must have a file, or stream, or source from which they can be played: but some streams might exist only on-demand (items from a web page), and some [[File Stacking\|stacked]] content items may have multiple on-disk files. Content::GetMedia should provide a single stream that can be accessed by the media player, even though it might encapsulate multiple on-disk files. (The idea is somewhat like the current FileItem, but with a lot less baggage.)

Martijn at 08:12, 2 September 2013

2013-09-02T08:12:52Z

← Older revision		Revision as of 08:12, 2 September 2013
Line 1:		Line 1:
			{{mininav\|[[Development]]}}

	As part of the present [[Database Schema 4.0a\|database redesign]], I decided to examine more of a "top down" view of the world, and from there extrapolate what the database should look like. What would the ideal interfaces between the file and content management parts of XBMC, and the rest of the application, look like? There are some primary requirements for these interfaces:		As part of the present [[Database Schema 4.0a\|database redesign]], I decided to examine more of a "top down" view of the world, and from there extrapolate what the database should look like. What would the ideal interfaces between the file and content management parts of XBMC, and the rest of the application, look like? There are some primary requirements for these interfaces:

>MoratNZ: Removed link spam

2011-09-28T09:25:54Z

Removed link spam

← Older revision		Revision as of 09:25, 28 September 2011
Line 97:		Line 97:

	*** This document is incomplete; further work to come.		*** This document is incomplete; further work to come.
	~~Also see [http://www.superiorpapers.com/ custom term papers]~~

	[[Category:Development]]		[[Category:Development]]

>NedBot: Robot: Cosmetic changes

2011-09-07T16:08:54Z

Robot: Cosmetic changes

← Older revision		Revision as of 16:08, 7 September 2011
Line 1:		Line 1:
	As part of the present [[~~Database_Schema_4~~.0a\|database redesign]], I decided to examine more of a "top down" view of the world, and from there extrapolate what the database should look like. What would the ideal interfaces between the file and content management parts of XBMC, and the rest of the application, look like? There are some primary requirements for these interfaces:		As part of the present [[Database Schema 4.0a\|database redesign]], I decided to examine more of a "top down" view of the world, and from there extrapolate what the database should look like. What would the ideal interfaces between the file and content management parts of XBMC, and the rest of the application, look like? There are some primary requirements for these interfaces:

	* They should hide the implementation; e.g., clients (other parts of the code) shouldn't need to know a database is involved.		* They should hide the implementation; e.g., clients (other parts of the code) shouldn't need to know a database is involved.
Line 99:		Line 99:
	Also see [http://www.superiorpapers.com/ custom term papers]		Also see [http://www.superiorpapers.com/ custom term papers]

	[[~~category~~:Development]]		[[Category:Development]]

>Valera at 15:41, 13 October 2010

2010-10-13T15:41:24Z

← Older revision		Revision as of 15:41, 13 October 2010
Line 97:		Line 97:

	*** This document is incomplete; further work to come.		*** This document is incomplete; further work to come.
			Also see [http://www.superiorpapers.com/ custom term papers]

	[[category:Development]]		[[category:Development]]

>Dbrobins at 07:14, 28 September 2010

2010-09-28T07:14:48Z

← Older revision		Revision as of 07:14, 28 September 2010
Line 97:		Line 97:

	*** This document is incomplete; further work to come.		*** This document is incomplete; further work to come.

			[[category:Development]]