Docker Container Categories


Recommended Posts

Phase 3 of the Community Repositories plugin is now more or less complete.

 

(For those interested, phase 1 was my initial proof of concept written in Bash of all things, phase 2 was the rewrite into PHP - many thanks to gfjardim and bonienl for their assistance with this).

 

Phase 3 is moving the plugin towards more of an appstore application.

 

When push comes to shove, the focus of dockerMan, and the current CR plugin is around that of repositories instead of where it belongs - the containers.  After all, all the end-user cares about is finding the container which suits their needs.  Phase 3 should put that focus back onto the containers themselves.

 

However, in order to accomplish this there is one thing missing.  Categorizing the containers.  What kind of app is it.  Is it a Backup application?  Is it a Media Server? etc.

 

And for this, I need everyone's help -> most importantly, I need the repository maintainer's help - They after all are the ones who are going to have to modify their XML templates to support this feature.

 

Below is a picture from my latest build of this, so that you can get an idea of how easy it will (should) be for users to find and use their containers.

 

Untitled_zpskp9ovdip.png

 

My initial thoughts on categories are:

 

Backup - Things like Crashplan

Cloud - Dropbox

Downloaders - Sabnzbd, CouchPotato, etc

Internet / Web - Apache, duckDNS, etc

Media Applications - Handbrake, Koma, etc

Media Servers - Logitech Media Server, Plex, etc

Productivity - Libre-Office, taskboard, etc

RDP - Any of those containers utilizing Hurricane's X Image

Tools / Utilities - Dolphin, DUC, etc

Other - One of a kind stuff - not easily classified, etc

Beta - Beta containers - stuff that does not work quite right, etc.  (This is also a special category, since I classify any container that's contained within a Beta Repository (smdion, Sparklyballs, Zuhkov) or that's explicitly categorized as being beta)

 

Should we for example further differentiate Media Applications and/or Servers to specify music / video?

 

Note that the new plugin already has the ability to support a container belonging to one or more categories.

 

We as a group need to come up with a categorization system that all of the repo maintainers can live with that is also easily understood by all - users and maintainers / authors.

 

This is not to say that we have to come up with a system right now that is set in stone until the end of days.  The application is expandable for future categories.  For example, currently there are no "games" containers published.  But, I'm sure that eventually someone somewhere will create one.  The system can be expanded to support that.

 

What I'm interested in right now is categorization for containers that already exist, or will exist in the near future.

 

After we as a group can decide upon a system that everyone can live with then we can begin to really make the docker system even easier to use.  After all, everyone out there knows how to install an app from their phone.

 

Note to repo maintainers:  Beyond a one line addition to XML template, nothing else changes from your point of view.  Users can still search and see which repository the containers are from so that they can choose to use BinHex's versions instead of Gfjardim's version.  The only fundamental difference is that the plugin no longer supports ADDING a repository to dockerMan.  There's no real need for it anymore.

 

I believe that we are on the cusp of an explosion in containers being created for unRaid, and that a system such as this is needed sooner rather than later, and will only increase utilization of the Docker system.

 

PS.  If anyone wants to try out the new plugin to see how its going to work, drop me a PM.  I have created a categorized repository (thank you sparkly) for demonstration purposes of the new features.

 

Thanks,

 

Squid

 

Link to comment
  • Replies 80
  • Created
  • Last Reply

Top Posters In This Topic

Except for Guacamole, for example, an RDP category is putting the focus in another place where it shouldn't be; i.e., the implementation details. Calibre-RDP for example is really not about RDP, it is about maintaining an ebook library. It just happens to use RDP to provide its user interface in a web browser.

Link to comment

I agree on the RDP part. Focus on what the container does instead. Other than that I think it's a pretty good idea as long as I can still sort by all. I'm still behind on whatever I was supposed to do to update my template a month ago so I'm probably not the best docker "developer" to weigh in on anything :)

 

Is there an xml template I can work of off?

Link to comment

Instead of focusing on a single category, allow for tagging of multiple items, then allow for browsing via the metatags.

 

For instance:

Comic Books

Organiser

Multimedia

Rpd

Web

Streamer

Productivity

Office

Music

Tv

Movies

Music

Download

Usenet

Torrent

Network

server

 

This way Calibre could be tagged with rdp, organiser, comic books

Nzbget could be tagged with download, usenet, movies, tv, multimedia

Emby could be web, streamer, multimedia, movies, tv, music

 

It doesnt have to be exactly as that, but you get the idea. Applying a single classification will never work, but allowing for multiple classifications/metatags will.

Link to comment

I agree on the RDP part. Focus on what the container does instead. Other than that I think it's a pretty good idea as long as I can still sort by all. I'm still behind on whatever I was supposed to do to update my template a month ago so I'm probably not the best docker "developer" to weigh in on anything :)

 

Is there an xml template I can work of off?

Not until we come up with a bunch of categories (metatags) which we can all work with.  Otherwise there will wind up being far too many and we will wind up back into the same boat (worse actually)
Link to comment

Instead of focusing on a single category, allow for tagging of multiple items, then allow for browsing via the metatags.

 

For instance:

Comic Books

Organiser

Multimedia

Rpd

Web

Streamer

Productivity

Office

Music

Tv

Movies

Music

Download

Usenet

Torrent

Network

server

 

This way Calibre could be tagged with rdp, organiser, comic books

Nzbget could be tagged with download, usenet, movies, tv, multimedia

Emby could be web, streamer, multimedia, movies, tv, music

 

It doesnt have to be exactly as that, but you get the idea. Applying a single classification will never work, but allowing for multiple classifications/metatags will.

As I mentioned in the OP, the system does allow for a container belonging to multiple categories (maybe groups would be a better term).

 

Narrowing it all down to TV, and movies is a little more detail than I was thinking of, but that's what we're here for.  To try and come up with a workable system.

 

The problem is that until we get close to coming up with workable groups that cover most if not all of what is at least out there right now we can't implement the system.

Link to comment

Why do the groups have to be predefined? They dont.

 

The implimentation doesn't require the metatags list ahead of time.  It merely needs to read the metatags from the repolist and iterate over the distinct metatags. No need for a definitive list.

Link to comment

Is there an xml template I can work of off?

This is my test repo I forked off of sparklyballs:  https://github.com/Squidly271/TestRepo/

 

If you look at it, you'll see that for simplicity and ease of implementation on the maintainer's part, there is only a single new element to the schema <Category>

 

Within that are the actual categories that the container belongs to.  Those entries can be of the form of "Category 1/Category 2", "Category 1, Category 2", "Category 1 Category 2".  Categories (groups) are handled as just a specialized search.  Capitalization is not important.  Delimiters between categories are not important.  Spelling however would be.  I'm tossing around the idea of a quick and dirty script once we get the categories / groups set  to assist everyone in modifying their xml's.

Link to comment

Why do the groups have to be predefined? They dont.

 

The implimentation doesn't require the metatags list ahead of time.  It merely needs to read the metatags from the repolist and iterate over the distinct metatags. No need for a definitive list.

Until you get maintainer calling tagging his containers as "X".  Maintainer B tags his containers as "Y".  Maintainer C tags his containers as "Z".

 

Now the system would show you three different tags for three very similar containers, and the net result is that the user is not going to be able to find what ever they want.

 

And, if you wind up with hundreds of different tags, I would think that you're in an even worse situation in trying to actually find something. 

 

A generalized category / group is how I believe every other app store out there works.  Anything else could be handled through searches.  My opinion at least.

Link to comment

Right, but you can build the display UI and functionality before that last is complete and finalized.

Already built.  I don't want to try and impose my opinions on the maintainers, have them modify the xml's to suit, and then keep having the debate and possibly forcing them to conform to a different system.  If it happened to me, I'd be annoyed.

 

Maybe we could do large very generalized categories.  Selecting them could take you to a sub-category display.  IE:  Category like Media Server, which then takes you to sub categories TV, Movies, Books, etc.

 

The list doesn't have to be finalized.  There's always room to add more.  But it at least has to be somewhat close.

 

Link to comment

I both agree and respectfully disagree with some of the points made so far:

 

I agree with the ideas of the original post, I think pre-decided general tagnames (allowing multiple tags to be used) as a starting point seem the easiest to implement without a mass of duplicate tags appearing.

 

I think allowing users to create tags initially could result in the following:

 

Problem: Tags for exactly the same classification appearing in many variations due to varied user inputs

Eg: "TV", "Tv", "tv", "Television"

 

Solution: As suggested, a list of general classification terms created so that maintainers can choose the term/terms to best describe their container and add these terms (easily) to their container XMLs. New terms would need to be added in the future I imagine with the increased development of docker containers, but we will cross that bridge as we go.

 

I agree with the exclusion of RDP as a category and think the categories suggested in the OP work pretty well but I'm sure there will be further discussion to possibly refine them.

 

Anyway,

 

Great work Squid!!

 

The Capt.

Link to comment

But don't you use RDP to do something? You don't RDP just to ... RDP. It's a means to an end; in the case of dockers a means to access the application that does the thing you want to do (like media encoding via handbrake).

 

If there is a meaningful reason to specifically call out RDP as the portal into a docker, vice another kind of access like a built in web portal, then having RDP as a "tag" makes sense. Otherwise it just seems like noise to the real signal that is the function a docker performs

Link to comment

 

Problem: Tags for exactly the same classification appearing in many variations due to varied user inputs

Eg: "TV", "Tv", "tv", "Television"

The plugin is currently case agnostic as far as categories.  EG: if we decide on a category called MEDIA, if the maintainer enters media or Media or MeDiA, it will all find it the same.  Tags if implemented in the future would also be similar, but once again TV is different than Television. 
Link to comment

But don't you use RDP to do something? You don't RDP just to ... RDP. It's a means to an end; in the case of dockers a means to access the application that does the thing you want to do (like media encoding via handbrake).

 

If there is a meaningful reason to specifically call out RDP as the portal into a docker, vice another kind of access like a built in web portal, then having RDP as a "tag" makes sense. Otherwise it just seems like noise to the real signal that is the function a docker performs

With the debate so far, I agree with the above.  RDP as a category doesn't make much sense (at least for things like Krusader, Dolphin, etc).  I've never run it, but would Guacamole still  qualify as RDP (ie: should the category still exist?)
Link to comment

But don't you use RDP to do something? You don't RDP just to ... RDP. It's a means to an end; in the case of dockers a means to access the application that does the thing you want to do (like media encoding via handbrake).

 

If there is a meaningful reason to specifically call out RDP as the portal into a docker, vice another kind of access like a built in web portal, then having RDP as a "tag" makes sense. Otherwise it just seems like noise to the real signal that is the function a docker performs

With the debate so far, I agree with the above.  RDP as a category doesn't make much sense (at least for things like Krusader, Dolphin, etc).  I've never run it, but would Guacamole still  qualify as RDP (ie: should the category still exist?)

 

a dip category ?

Link to comment

But don't you use RDP to do something? You don't RDP just to ... RDP. It's a means to an end; in the case of dockers a means to access the application that does the thing you want to do (like media encoding via handbrake).

 

If there is a meaningful reason to specifically call out RDP as the portal into a docker, vice another kind of access like a built in web portal, then having RDP as a "tag" makes sense. Otherwise it just seems like noise to the real signal that is the function a docker performs

With the debate so far, I agree with the above.  RDP as a category doesn't make much sense (at least for things like Krusader, Dolphin, etc).  I've never run it, but would Guacamole still  qualify as RDP (ie: should the category still exist?)

Guacamole allows you to connect to other desktops on your network. I think it was probably the inspiration if not a component in the rdp dockers. RDP is what Guacamole does.
Link to comment

But don't you use RDP to do something? You don't RDP just to ... RDP. It's a means to an end; in the case of dockers a means to access the application that does the thing you want to do (like media encoding via handbrake).

 

If there is a meaningful reason to specifically call out RDP as the portal into a docker, vice another kind of access like a built in web portal, then having RDP as a "tag" makes sense. Otherwise it just seems like noise to the real signal that is the function a docker performs

With the debate so far, I agree with the above.  RDP as a category doesn't make much sense (at least for things like Krusader, Dolphin, etc).  I've never run it, but would Guacamole still  qualify as RDP (ie: should the category still exist?)

Guacamole allows you to connect to other desktops on your network. I think it was probably the inspiration if not a component in the rdp dockers. RDP is what Guacamole does.

Since it seems to be rather unique at the moment, maybe the best solution would be to have it a member of something like Tools / Utilities instead of having it the only member of RDP.  If the situation changes in the future new categories can always be added.
Link to comment

But don't you use RDP to do something? You don't RDP just to ... RDP. It's a means to an end; in the case of dockers a means to access the application that does the thing you want to do (like media encoding via handbrake).

 

If there is a meaningful reason to specifically call out RDP as the portal into a docker, vice another kind of access like a built in web portal, then having RDP as a "tag" makes sense. Otherwise it just seems like noise to the real signal that is the function a docker performs

With the debate so far, I agree with the above.  RDP as a category doesn't make much sense (at least for things like Krusader, Dolphin, etc).  I've never run it, but would Guacamole still  qualify as RDP (ie: should the category still exist?)

Guacamole allows you to connect to other desktops on your network. I think it was probably the inspiration if not a component in the rdp dockers. RDP is what Guacamole does.

 

the RDP story started with hurricane finding it and using it in a container for tiny media manager, it was good but clunky.

 

guacamole  came along some time between that container and jonp posting a  desktop in a box video of the same tech, and hurricane revisited his original container and eventually ended up leveraging parts of guacamole to give us the base image for x apps in a browser.

 

if we're not having an RDP category, guac should probably end up in tools/utilities

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.