PDA

View Full Version : Update the OpenGL "SDK"



Alfonse Reinheart
10-28-2012, 03:30 PM
Well, since my last thread (http://www.opengl.org/discussion_boards/showthread.php/179131-Outdated-and-innacurate-documentation-on-OpenGL-org-considered-harmful) had the intended consequences (the http://www.opengl.org/sdk/docs/man/ link now goes to the 4.3 pages, not the dangerously misinformed 2.1 ones. They're still available via http://www.opengl.org/sdk/docs/man2/ which is fine), let's see if we can't improve other things on OpenGL.org.

This is the official OpenGL SDK (http://www.opengl.org/sdk/). When a normal person wants to learn about OpenGL and start using it, the first thing they see under "Code Resources" is this page. So it's fairly popular.

Short version: There is a lot of outdated junk and dead-links on the SDK.

Long version:

Let's ignore the fact that this "SDK" is nothing like an actual SDK (to the point where calling it an SDK is misinformation bordering on propaganda). This is what we've got. So... can it at least not contain useless things?

Let's walk through the "SDK"'s Libraries page. (http://www.opengl.org/sdk/libs/)

First, we have Equalizer (http://www.opengl.org/sdk/libs/Equalizer/). There are two problems here. Equalizer is a tool for multi-processed OpenGL execution. People who look for "SDK"s are not going to be doing multi-processed OpenGL. These people are on the "Hello, World!" level of OpenGL. This is just not appropriate for a tool that is part of an "SDK". It's too specialized and required advanced knowledge that people who want an SDK won't be looking for. At the very least, it shouldn't be the first link new users see.

But I'm sure this is a fine tool, worthy of note. Or, rather, it was, when it still existed.

Here's a great way to make OpenGL look dead: have a lot of dead links on the OpenGL site itself. If OpenGL.org doesn't look like a place that's being actively maintained, then OpenGL looks like dead technology. And if the official SDK site for OpenGL is composed of dead links, then OpenGL looks even more dead.

Which brings us to GLee (http://www.opengl.org/sdk/libs/GLee/). Which contains more dead links. Not to the main GLee site, but to the downloads from that site which now no longer exist. Indeed, in order to get GLee, you now must install Git and clone it from the Git repo on SourceForge.

Not exactly a vibrant project when they can't even be bothered to have packaged download. Another way to make OpenGL look dead is to link to a bunch of dead projects in support of OpenGL.

The GLEW (http://www.opengl.org/sdk/libs/GLEW/) and GLM (http://www.opengl.org/sdk/libs/GLM/) pages are OK, though no mention is made of GLEW's problems with core contexts.

Then we have a link to libktx. Really? Of all the many, many image loading libraries out there, you picked that one? Something used primarily by GL ES, even when it is used at all. It has little tool support (Googling for "Photoshop KTX plugin" turned up zilch), little visibility outside of its specialty, and it's documentation is an obvious minimal-effort Doxygen job.

Oh, and even better? There's this little gem right before the downloads: "The bundle includes OpenGL ES applications showing how to use the library to load textures." OK, how about some examples in desktop OpenGL? You know, the OpenGL that the "SDK" is actually supposedly about.

So the "SDK" not only makes OpenGL look dead, it makes OpenGL look dead and confused.

And we end the library section with OpenSceneGraph (http://www.openscenegraph.org/projects/osg/wiki/Downloads), which is an actual project with developers and everything. It is a tool that is useful to many. And... it has poor support for modern OpenGL features. But that's semi-minor compared to the other things on that page.

The Tools page is better, in that it has fewer dead-links. Though the link to Shader Designer (http://www.opengl.org/sdk/tools/ShaderDesigner/) is rather dubious, since Typhoon Labs (http://www.typhoonlabs.com/) is defunct.

There's even a dead-link on the Communications page (http://www.opengl.org/sdk/communicate/): the link to the pipeline newsletters which no longer exist on OpenGL.org (thanks for removing those, btw. They didn't have great and useful articles like "When Shaders Attack" or anything...).

Solutions:

If the "SDK" is going to remain in sarcasm-quotes, then at the very least, there needs to be some form of maintenance done on the links. Dead-links and links to defunct projects should be pruned. Links to new projects should be added.

A more permanent solution is to move the "SDK" to the Wiki, where it can be more reasonably maintained. If a link goes dead, it can be removed. If someone wants their project listed, it can be added. And so on. Indeed, we already have such a page (http://www.opengl.org/wiki/Related_toolkits_and_APIs); it's far more useful than the "SDK" page.

eile
10-29-2012, 06:15 AM
First, we have Equalizer (http://www.opengl.org/sdk/libs/Equalizer/). There are two problems here. Equalizer is a tool for multi-processed OpenGL execution. People who look for "SDK"s are not going to be doing multi-processed OpenGL. These people are on the "Hello, World!" level of OpenGL. This is just not appropriate for a tool that is part of an "SDK". It's too specialized and required advanced knowledge that people who want an SDK won't be looking for. At the very least, it shouldn't be the first link new users see.

But I'm sure this is a fine tool, worthy of note. Or, rather, it was, when it still existed.


Not sure what you're referring to. Equalizer does exist and is under active development. This weekend our server did not survive a reboot (first time in seven years...), we're working on it with the hosting provider. The source repo at https://github.com/Eyescale/Equalizer is very much alive.

I agree it doesn't have to be first on the list.



A more permanent solution is to move the "SDK" to the Wiki, where it can be more reasonably maintained. If a link goes dead, it can be removed. If someone wants their project listed, it can be added. And so on. Indeed, we already have such a page (http://www.opengl.org/wiki/Related_toolkits_and_APIs); it's far more useful than the "SDK" page.

That sounds like a fine solution for me too. Maybe make it easy(er) to find?

Khronos_webmaster
10-29-2012, 10:03 AM
We'll be keeping the SDK where it is and not moving it to the wiki, at least for the time being. Time is our limitation, but those involved are doing their best to keep the SDK up-to-date.


Here's a great way to make OpenGL look dead: have a lot of dead links on the OpenGL site itself. If OpenGL.org doesn't look like a place that's being actively maintained, then OpenGL looks like dead technology. And if the official SDK site for OpenGL is composed of dead links, then OpenGL looks even more dead.

Broken links pointing into the man pages are new as of last week when we updated the man pages at your request. We didn't catch all the broken links around. Now that we know about them, we'll get them fixed up.


Which brings us to GLee. Which contains more dead links. Not to the main GLee site, but to the downloads from that site which now no longer exist. Indeed, in order to get GLee, you now must install Git and clone it from the Git repo on SourceForge.

Not exactly a vibrant project when they can't even be bothered to have packaged download. Another way to make OpenGL look dead is to link to a bunch of dead projects in support of OpenGL.

Most of the project in the SDK are maintained by the author of those projects and not by OpenGL/Khronos. As such, I've passed on your message to the GLee maintainers about the broken links in the SDK, and asked them to update their links. I'm curious though, does this link (http://glee.svn.sourceforge.net/viewvc/glee/?view=tar) not download a tarball of GLee from the SVN repository available on Sourceforge? I didn't need to install Git and the link seemed to be a decent packaged download.


Then we have a link to libktx. Really?
If anyone should happen to find a "bug" on the SDK pages, or a suggestion for alternative libraries etc, please feel free to post them in our Bugzilla (https://www.khronos.org/bugzilla/) linked to from the main SDK page.


And we end the library section with OpenSceneGraph (http://www.openscenegraph.org/projects/osg/wiki/Downloads), which is an actual project with developers and everything. It is a tool that is useful to many. And... it has poor support for modern OpenGL features. But that's semi-minor compared to the other things on that page.
Perhaps worth mentioning the poor support to the folks who run the OpenSceneGraph site?

Thanks for your feedback and continued support on helping to get and keep the SDK in better shape.

Alfonse Reinheart
10-29-2012, 02:27 PM
Not sure what you're referring to. Equalizer does exist and is under active development. This weekend our server did not survive a reboot (first time in seven years...), we're working on it with the hosting provider. The source repo at https://github.com/Eyescale/Equalizer is very much alive.

A case of unfortunate timing then. I saw that the link was dead, and there was no dedicated Wikipedia article (my general dividing line between what's popular enough to matter and what isn't), so I figured the project was dead. Sorry about that.


Most of the project in the SDK are maintained by the author of those projects and not by OpenGL/Khronos.

Obviously the projects are maintained by the individual owners, but ultimately OpenGL/Khronos decides what to host (and therefore what not to host). Shouldn't there be some kind of "standard of duty" for a project that gets a semi-official stamp from OpenGL/Khronos? Some minimal level of functionality that OpenGL/Khronos requires them to achieve before they can have/maintain their place on OpenGL.org?

At the very least, such libraries should have download packages and reasonable documentation. Without these, it's just some repo somewhere with random source code. Personally, I would take it farther. For example, for loading libraries, there should be a basic requirement that they support OpenGL 4.3 within a month of the .spec files' release, as well as provide full support for core contexts. Libraries not meeting this requirement should be informed of their failure to comply with standards and that their project will be de-listed from the SDK if they do not come into compliance.

The whole point of the "SDK" is to promote these libraries as the best of the community, right? So why is there no standard for actually determining if they are the best of the community? Being in the "SDK" is a privilege; it should also come with responsibilities to the OpenGL community.


I'm curious though, does this link not download a tarball of GLee from the SVN repository available on Sourceforge? I didn't need to install Git and the link seemed to be a decent packaged download.

True, but the SVN repo hasn't had a write in a year and a half (http://sourceforge.net/projects/glee/stats/scm?repo=SVNRepository&dates=2010-01-01+to+2012-10-29). It's clearly obsolete, as the GIT repo at least has seen writing within this year (http://sourceforge.net/projects/glee/stats/scm?repo=GitRepository&dates=2012-01-01+to+2012-10-29). The SVN repo would not be the first place one would look for downloads.

But my main point is that if a library's author isn't confident enough to provide a real release (thus forcing users to go searching for one), then it's probably not something that should be showcased by the "SDK".


If anyone should happen to find a "bug" on the SDK pages, or a suggestion for alternative libraries etc, please feel free to post them in our Bugzilla linked to from the main SDK page.

That's a rather... odd means of getting new libraries onto the pages. Generally, people don't use Bugzilla for this sort of thing. Also, it's unclear as to exactly what kind of "bug" that would be filed under.

BTW, are you aware that the ability to browse certain bugs is broken in the Bugzilla (https://www.khronos.org/bugzilla/show_bug.cgi?id=691)? Because it really feels like bugs filed under that heading just sort of get lost. And since these kinds of "bugs" would fall under that heading, that's probably something you guys need to get sorted out.

Brandon J. Van Every
11-11-2012, 01:17 AM
Short version: There is a lot of outdated junk and dead-links on the SDK.


+1



Long version:
Let's ignore the fact that this "SDK" is nothing like an actual SDK (to the point where calling it an SDK is misinformation bordering on propaganda).


Why?

Khronos could solve a number of OpenGL "fit and finish" problems by abandoning this seriously misguided attempt to pretend they're in the business of providing an SDK. They're not. It bothers new developers quite a bit, to go on wild goose chases for stuff that doesn't even work and isn't relevant. Puts some people off to OpenGL, I'm sure.

If you don't call it "SDK," and just call it "collection of libraries," people would get less upset. Better yet: curate / categorize those libraries according to appropriate functionality. Also consider rating them somehow, or displaying their most recent commit status, or purging them when challenged according to some objective criteria. If Khronos is not willing to do any kind of checking on what the libraries are, then why is it giving them top bill advertizing space on opengl.org? I'm sure lots of people would like to advertize in those spots if it's really for totally random OpenGL libraries of random quality.

I can't imagine Microsoft allowing a bunch of random libraries of murky quality to get top billing on their DirectX site. The Khronos business model here is completely, utterly dumb. Don't you guys care about your brand identity at all? And doesn't that mean some audience other than hard core open source developers who will gladly put up with any old broken gizmo?