There are several rules of thumb for deciding what features you need, the best being “Waste not, want not” and “Say what you mean and eat what you take.” OK, seriously though… to answer this question we need to understand what features are, and where they are defined.
A feature is the way an application tells the container (in this case the Jive instance/app-sandbox) what capabilities it needs to function properly. For example, if you are going to get information about people, activities, etc. you need to tell the container that you REQUIRE the OPENSOCIAL APIs.
When the container processes the application definition, it looks at the features the app requires and compares it with the features it supports. If there’s a match, life is good and your app is rendered. If not, then an error is returned.
In some cases you can incorporate logic in your app that tells the container that it’d be nice to have a feature, but it’s not required. That is, support for the feature is OPTIONAL. For example, you might want to use minimessge, but if the container does not support it, you put some branching logic in your code to display a dialog box.
You can find out if a container has the feature by issuing the hasFeature call.
If the feature has parameters, you can get this by a similar call:
To understand what features are available to you, let’s look at where they get defined. The first place they get defined is in the OpenSocial specification. In addition to the base set of capability you get just by being an app (e.g. what's available in the gadgets namespace), you can look in the Core Gadget specification, section C. The Social Gadget specification explains the OSAPI calls that are in that feature. OpenSocial layered the specification in such a way that if you had the case where you used no social data, you did not have to bring along a bunch of extra stuff you don’t need.
The nice thing about features is that they provide a clean way for container providers, e.g. Jive to extend the system. This is exactly what the jive core and jive connects features are. Because OpenSocial doesn’t define everything that’s in Jive, e.g. no blogs, discussions, we wanted a way to provide access to that information using the EXACT SAME PROGRAMMING MODEL. This allows the app developer (you) all kinds of benefits, not the least of which is having to learn only one way of doing something.There is a table below that contains a list of the Jive features.
So now that we know what features are, how do I know which ones I need? I’ll go back to my initial comments, “Waste not, want not” and “Say what you mean and eat what you take.” That is, when you understand what you want your app to do, find the right features to help you accomplish it, and don’t REQUIRE anything more.
The following tables identify extensions, features, services, and views that Jive provides beyond the OpenSocial Services:
Internal. Adds the jive.namespace() function for creating additional namespaces under jive.*
|jive-custom-settings-1.0.0||An extension used to close the popover, refresh the app and show a success message. This is typically uses with OpenSocial's setprefs feature.|