Praisegawd / navi-x

Automatically exported from code.google.com/p/navi-x
0 stars 0 forks source link

Playlist Re-Structuring Discussion #108

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
The main objective of this discussion is to streamline content additions to 
Navi-X and make the process simple and easy for all users involved in content 
additions on Navi-X.

The questions being asked are from Tikkiew and I will put my personal notes 
here in regards to these questions. The community of users and the rest of the 
team can comment anytime on any notes and feel free to be apart of this 
discussion. Realize however, only Tikkiew and I will be implementing the 
changes afterwards so while many may have great suggestions, it will be our 
decision exclusively on how to progress from here.

Based on my discussion with Tikkiew, he feels two areas of concern should be 
looked at...

1. Using JSON or PLX going forward with playlist creation and management.
2. Using 1 big list for content or sub-playlists.

Here are my reponses to each suggestion:
1. While JSON is undoubtedly the standard for API interaction in Boxee and 
XBMC, creating JSON based playlists poses several challenges... people who want 
to add content to playlist can easily break functinality for all other users if 
they are not familiar with java syntax and restrictions. The nice thing about 
the PLX format is that it is very forgiving when a user or team member goofs 
JSON syntax. You also don't need to know syntax restrictions of JSON and the 
PLX format is very easy to use. Also, we no longer have a developer who we can 
resolve JSON complications or compatibility issues with, so if we mess up the 
current setup, we are out of luck in terms of support. In short, STRICTLY FOR 
CONTENT ADDITIONS ONLY, I say we continue to use PLX formatting. If someone 
wants JSON output of our PLX's, they can use Turner's PLX to JSON converter to 
obtain this output. The JSON output would only be important to non-Boxee or 
XBMC devices and even then, the output still needs to be parsed in a playlist 
by a platform dev so the JSON would work anyways. It's not like it is any less 
proprietary in my view when compared to the PLX format. The fact that PLX 
formatting is forgiving and easy to update via ftp makes it seem my choice 
preference for content additions.

2. As for 1 big list or sublists under discussion, I think it's pretty apparent 
that even major companies are making a distinction among content and 
categorizing it, even at a minimal level... so I'm in favor of sub-categories 
for content... how to categorize this is an easy answer for me... simply like 
how companies like AppleTV and others do.... by content type. Sources providing 
both movies and tv shows should be separated in each respective section. As for 
determining what content is full content and just clips, this distinction 
should be made from now on. While TRUTV is typically it's own full broadcast 
channel with full episodes, the website only provides video clips of content, 
thus it would not go under TV Shows, but Video Sources. I would like to hear 
Tikkiew's clarification on what he means by this.

This is the beginning of the conversation but if anyone wants to chime in, now 
would be a good time! Thanks!

iRoNBiLL

Original issue reported on code.google.com by billdaly111@gmail.com on 6 Dec 2011 at 11:57

GoogleCodeExporter commented 8 years ago
2.
I wasn't referring to 1 big list for users. But for us people that maintain the 
main playlist. The discussion started how me maintain that. I wish the apps 
didn't use different ways.

On Boxee Navi-X 4. we use one big list/file on (sources.json) on googlecode 
http://code.google.com/p/navi-x/source/browse/trunk/Navi-X%20BOXEE/source/data/s
ettings/sources.json

On XBMC Navi-X and Boxee Navi-X 1.4
we maintain Navi-X with multiple plx files. And use subfolders.
http://code.google.com/p/navi-x/source/browse/trunk/Playlists/home.plx
http://navix.turner3d.net/playlist/50242/navi-xtreme_nxportal_home.plx
Which is divided by multiple playlist and subplaylists. And hosted on different 
sources.

Basically use 1 way for all app to maintain the home/main playlist(s). This 
makes it less work for us to maintain that.

1. Using JSON or PLX 

Again the discussion started about that we want 1 way to maintain home/main 
playlist(s) for all the apps. So we need also choose if we are going to use 
JSON or PLX for maintaining the home/main playlist(s).
Yes PLX format is more user friendly to use. But honestly JSON isn't that hard 
to understand. So if we use sources.json or home.plx. I can live with either 
way.

offtopic :
Either if the apps/addon in the future allow JSON or PLX or both on the apps. I 
see this should be more a discussion betweeen the devoloper(s). I am not a 
developer.

But why is there type=json on Boxee Navi-X 4? Is the big idea to use JSON 
instead of PLX? Will we be adding type=json in the other apps/addons? If he 
last question is a no. Than we shouldn't be using type=json on Boxee Navi-X 4. 
If yes, than I request type=json should be added in the other apps/addon in the 
future.

Original comment by tikkiebr...@gmail.com on 7 Dec 2011 at 3:44

GoogleCodeExporter commented 8 years ago
Okay... the ONLY reason JSON was used in Navi-X 4 rather than PLX was because 
Bart felt it would be better to use JSON... an independent decision made by the 
app developer without consulting the rest of the team really... this is why it 
is the way it is now.

That does not mean this cannot change. I agree we should use one or the other, 
hence why I am big on wanting to bring everything into uniform sync between 
apps and what initiated this conversation in the first place. I think since PLX 
is a Navi-X native format and has already been implemented, we should continue 
to build on the work we have done and not "reinvent the wheel".

I propose creating a PLX playlist for all major categories in Navi-X 4 and 
simply putting all entries on these playlist. It would probably be better to 
just link directly to these in a GoogleCode repository since it is very much 
like ftp, using the current setup brought about on Box, but transferred to 
GoogleCode not as Docs but as files in a repo since this is similar to how we 
used to update Navi-X Networks anyways. It's fast and easy to submit changes 
and can be easily fixed by restoring files from a backup folder.

I will attempt to investigate direct PLX integration into Navi-X 4. We will 
retain JSON capability since Boxee rely's on this still, but we will attempt 
direct linkage and usage of PLX's instead of sources.json.

I will update notes here when I figure out how to accomplish this.

Bill

Original comment by billdaly111@gmail.com on 7 Dec 2011 at 5:58

GoogleCodeExporter commented 8 years ago
Quote bill : I will attempt to investigate direct PLX integration into Navi-X 
4. We will retain JSON capability since Boxee rely's on this still, but we will 
attempt direct linkage and usage of PLX's instead of sources.json.

That's why I said you post this request here. Since some developer needs to 
adjust the app to make that work. As all other bugs and request posted here. 

Original comment by tikkiebr...@gmail.com on 9 Dec 2011 at 7:28

GoogleCodeExporter commented 8 years ago
It has been determined Navi-X Beta will be shelved from support and re-named 
Navi-X Remix and distributed "as is" with original defects and errors. Ticket 
closed.

Original comment by billdaly111@gmail.com on 23 Jan 2012 at 10:45