In an attempt to make things more clear and organized I've decided to start from the beginning and try to make a rough outline. I think this will be a little more to the point and easier for others to contribute to. So here's starting fresh.....

Words/phrases that need better wording

  • web applications/services
  • plugin meta-package

Current web integration

  1. Built-in
    1. Advantages
      1. Full support by application developers.
      2. Users can file bugs against the application.
    2. Disadvantages
      1. More code to manage for developers.
      2. Web applications/services don't always maintain api stability.
        1. If the api is closed, it is often more volatile, and each application must reverse engineer it to fix the bugs introduced by the change.
        2. Developers must make a new release with the changes. Or, the developers could leave the broken support until their next scheduled release.
        3. Distributions often take a long time to release new versions of applications so there is a potential for the web application/service support to be broken for quite a long time from the user point-of-view.
  2. Plugin/Extension
    1. Advantages
      1. Developers only have to focus on developing and bugfixing the plugin framework.
      2. The application stays slim for those that don't use the plugins
      3. The application UI doesn't become cluttered with options used for all of the different features
      4. Developers interested only in the integration aspect of a particular web application/service can focus on that code, and not worry about learning the internals of an application beyond the plugin hooks.
      5. If a web application/service changes its api, the developers of that particular plugin can make the appropriate fixes and release a new version of their plugin independent of the main application.
      6. Allows the application to use web applications/services beyond what the developer cares about.
    2. Disadvantages
      1. Plugin interface is clunky
        1. Application usually has a “Plugins” dialog accessible from the menu. From here, the user must select which extension they want to configure and open that extensions dialog box. From there they could be greeted with more tabs of configuration.
        2. Plugins don't always follow the applications “vision”. The configuration dialog is often not designed in a user friendly manner.
        3. Preferences, as a whole, loses its flow.
      2. Developers often get extraneous bug reports for plugins that they aren't responsible for.
      3. Applications are graded down because of how certain plugins behave when they are not to blame.

Failures of both integration systems

  1. Each web application/service must be reimplemented in every application.
  2. The user must configure their web accounts for each application, often with different options in each.

Web Integration Framework

  1. A generic plugin framework
    1. Doesn't have to be unique to just web based plugins
  2. Generic Integration Specifications
    1. Provides specifications of default integration possibilities for different groups of data
    2. Allows all programs to access relevant data and have basic integration of web services
    3. Possible categories (should flesh out spec by doing mock integration writeups for many different web applications/services)
      1. Audio
        1. Send/Receive current song metadata
      2. Video
        1. Send/Receive current video metadata
      3. Contacts
        1. Contact store
      4. Bookmarks
  3. Application specific integration
    1. Allows plugins to interface more extensively into specific applications. This will only effect the targeted applications, but the user still only has to install one plugin for the web application/service.
  4. Site Plugin (Meta) Package
    1. Provides base information integration
    2. Provides application specific integration
      1. This might possibly be done using a metapackage so only application specific integration for the installed applications would be installed/downloaded.
        • This would require the plugin manager to be aware of what applications are installed on the system. Through .desktop files?
        • This may also make it awkward when installing new applications if the specific integration isn't ready yet because the piece of the metapackage is still downloading.

Possible User Interaction

And my old explaination....

Web Services Framework

What is the problem you are trying to solve?

It's easy enough to say that online integration is the way of the future, but its implementation is a challenge. The way that this currently works is generally by extensions implemented for each application. The reasons for this is that not everybody uses the web services that the applications support so all of the extra options are just cruft to them. Also, the extensions work well because if parts of the web service changes that needs to be updated to work in the application, you don't have to release a new version. You can just update the version of the plugin independent of the application. It is definitely not optimal, however, for every application to implement their own type of web service extension framework and to have to write plugins with close to the same functionality for the growing number of web services.

Describe your Idea/Solution

Low Level Implementation

What I propose is a centralized web services framework. The way it works is that each application implements the base framework for their media/data type. You will install one plugin for a web page (Last.FM for example) and that plugin hooks into the different areas of the base framework that make sense for it. In the Last.FM example, the plugin would register its radio stations and currently playing song output with the media framework. It would register its contacts list and private messages notification with the contacts framework. Beyond the base framework, it can provide closer integration for specific applications, like providing the Recommended Artists and Track Ratings panes for Banshee. So if you have Banshee you get some really cool features, but if you use a more obscure music player, you will still get some of the integration. If you install the GMail plugin, it would register its contacts, set itself as a handler of mailto:, register with the notification framework, and create an application icon.

User Implementation

For the user, the issues are how to discover, add/remove, and configure the plugins. The way I see it working is that a trusted plugin list (provided by gnome or the distribution) would be referenced either loaded on the fly as needed, or periodically synced. There would be multiple ways to discover what plugins are available. When a user is browsing the internet, if a domain has a plugin available (as checked against the trusted list) the user would get a non-obtrusive signal from the browser. This could just be an icon that shows up in the location bar like RSS feeds do now. When they click on it, they would be given information about the type of integration that it would provide and an option to install it. If they click on the icon when they already have the plugin installed, they should be presented with the plugins global preferences. Another way that they could install plugins is to use the plugins-manager. I imagine this application looking very much like Ubuntu's "Add/Remove..". application. From here they should be able to search for plugins and be provided with information for each one of them and the option to install. If an application is already installed here, there should be an option somewhere in the interface to also access the global preferences. Another way to install a plugin is from a application. For example, if the user were using Totem they should be able to click on the "Web Services" menu item. This will bring up the the app-plugin-manager. This would look very much like what Rhythmbox and Banshee's plugin manager looks like today. The user can enable or disable a plugin for the current application only. They can also change any application specific preferences. In the app-plugin-manager there will be a link to get more plugins (as Firefox has). The link will bring up the plugin-manager with search results for plugins that work with that specific application. They could also install plugins downloaded from a page that is not in the "trusted list" with a warning about the possible ill effects from using the plugin (again a la Firefox). The plugins should also be able to easily update (NewStuffManager possibly [1]).

Mockups

These mockups are in no way what the final product should look/behave like. They are just here to help demonstrate my idea. http://i155.photobucket.com/albums/s314/jcmkk3/BrowserWebState.png

The browser in "web browsing" mode that has landed on a site with a potential web service.

http://i155.photobucket.com/albums/s314/jcmkk3/BrowserApp.png

The browser in "application mode" after the web service has been installed. Note the GMail program icon on the panel and the lack of navigational buttons in the web browser. It is also showing GMail's global settings dialog (note that the chosen settings are just there for example), which is invoked by clicking on the "web service" button when the service is already installed.

http://i155.photobucket.com/albums/s314/jcmkk3/Plugin-Manager.png

The Web Service Manager would look something like this (Ubuntu's "Add/Remove.." application).

External References

[1]http://www.k-d-w.org/NewStuffManager/

Attic/CentralizedWebServicesInformationIndexer (last edited 2013-12-03 23:36:30 by WilliamJonMcCann)