frontend classification

**tripzero** · 09-23-2009, 07:52 PM

A recent IRC discussion has led me to want to raise a valid question: "What is a frontend?". Depending on who you ask, you will get different answers. When analysed in simplest form, a frontend is:

A top-level application that does something for some other lower-level application.

When speaking of a CarPC frontend, the following definition usually applies in addition to the above:

A top-level applcation that plays media, launches and embeds external applications, performs a number of other things via plugins all in a unified touch friendly interface.

A traditional frontend replaces the system shell (which in windows is explorer.exe). This applies to all windows frontends and nGhost. However, in theory, a frontend can be run without a shell present. For example, in LinuxICE, there is no other shell present, nGhost IS the shell.

The differences in the frontends are in the design. The following is my own take on the different approaches:

Monolithic
A single process that does everything. No external apps required.

Embedable
Can embed external applications within its interface. This usually happens by telling the window manager to assign a window to one you have already created inside the frontend.

Pluginable
Can extend functionality dynamically.

Multi-Threaded
Performs various functions on multiple processing threads that share the same process space.

Multi-Windowed
runs different function in their own window.

Multi-Processed
Significant portions of the application run in a different process space some sort of communication between the respective processes.

So now that we have a classification, let's apply it to popular frontends:

Centrafuse: Monolithic, Embeddable, Pluginable
RevFE: Monolithic, Embeddable, Pluginable, Multi-threaded, Mutli-Windowed
nGhost2: Monolithic, Multi-Processed, Multi-threaded, Pluginable
RR: Monolithic, Embeddable, Pluginable
OpenMobile: Monolithic, Multi-threaded, Pluginable, Embeddable
nGhost3: Multi-Processed, Pluginable

Frontend Features:

Given the above design implementations, what is considered to be a feature of the frontend? For example, just because you can embed iGuidance into RR does that mean it has GPS support? Or just because someone has made a traffic plugin for Centrafuse, does that mean that it has a traffic feature?

For me, a feature of any given frontend is a type of functionality provided in the default shipment of the frontend. An example of this is nGhost ships with nScan, a separate application that provides out of process scanning and watching of media. Although the nGhost exe doesn't have built in functionality to scan media, the nGhost package comes with this functionality by default, therefore, it is a "feature" of the frontend.

This means that 3rd party plugins and apps are not considered features of the frontend.

I'd like to get other's thoughts on the topic. I want to write a wikipedia page on the frontend topic and could use some more insight.

thanks

**malcom2073** · 09-23-2009, 08:09 PM

I think that plugins and add-on applications can be considered the features of a frontend, but it would be considered more of an optional feature than an add on feature. For instance, RR can embed gps applications, so it has the ability to have a Navigation feature. That's up to the end user, but it is still a capability.

**tripzero** · 09-23-2009, 08:13 PM

Originally Posted by malcom2073

I think that plugins and add-on applications can be considered the features of a frontend, but it would be considered more of an optional feature than an add on feature. For instance, RR can embed gps applications, so it has the ability to have a Navigation feature. That's up to the end user, but it is still a capability.

We cannot define features based upon capability alone. Otherwise a frontend's features list would be endless if it implements a plugin system where developers can develop a plugin that does "the kitchen sink". By limiting features to what is shipped with the product itself we will cover the common denominator.

I agree though. It can be listed, but should be clarified that it is a 3rd party add-on feature and not a default/supported feature.

**justchat_1** · 09-23-2009, 08:13 PM

GREAT WRITE UP!! Not sure how many non-programmers would understand it but I thought it was a great summary.

Two things I might question though:
1. Isn't riderunner multi-processed? (Have you seen the number of executables running for some of the tasks it does)
2. Are third party plugins really not considered part of the app? I think it depends on how they're implemented. If an app has a "radio interface" with radio plugins that can be swapped out and changed around then technically its using third party plugins. But given the clear "support" for the plugin i would say its an extensible feature.

To be honest though its easier to say supported, supported via plugin and not supported....

Edit:
Apparently I took to long to write that... I think one clear distinction that should be made is that embedding another application should NOT count as a feature or even any amount of support for the category. Applications that have navigation as a feature....should have navigation internal or rendered through a plugin not just embed destinator.

**malcom2073** · 09-23-2009, 08:15 PM

Originally Posted by kev000

We cannot define features based upon capability alone. Otherwise a frontend's features list would be endless if it implements a plugin system where developers can develop a plugin that does "the kitchen sink". By limiting features to what is shipped with the product itself we will cover the common denominator.

Ah! therin comes the wonderful term: "Developer Supported" vs "Third Party" plugin/feature.

**tripzero** · 09-23-2009, 08:16 PM

Originally Posted by malcom2073

Ah! therin comes the wonderful term: "Developer Supported" vs "Third Party" plugin/feature.

Usually developer supported plugins/features ship with the product.

**malcom2073** · 09-23-2009, 08:18 PM

Originally Posted by kev000

Usually developer supported plugins/features ship with the product.

But they don't have to, I don't think the line should be drawn at what's shipped with the product, so much as what's considered supported. There are some frontends that ship with third party plugins, can you REALLY consider them to be features if they aren't developer supported?

**tripzero** · 09-23-2009, 08:28 PM

Originally Posted by justchat_1

GREAT WRITE UP!! Not sure how many non-programmers would understand it but I thought it was a great summary.

Two things I might question though:
1. Isn't riderunner multi-processed? (Have you seen the number of executables running for some of the tasks it does)
2. Are third party plugins really not considered part of the app? I think it depends on how they're implemented. If an app has a "radio interface" with radio plugins that can be swapped out and changed around then technically its using third party plugins. But given the clear "support" for the plugin i would say its an extensible feature.

To be honest though its easier to say supported, supported via plugin and not supported....

Edit:
Apparently I took to long to write that... I think one clear distinction that should be made is that embedding another application should NOT count as a feature or even any amount of support for the category. Applications that have navigation as a feature....should have navigation internal or rendered through a plugin not just embed destinator.

1. I have no idea. It's possible that this is true. Maybe we should clarify because there is a distiction: nGhost2 is multi-processed because it exposes an API to for other apps/processes to communicate with it. nGhost3 is multi-processed because plugins actually run in a separate process via "client.exe" similarly to how google chrome runs tabs in separate chrome.exe instances. (btw, i'm adding '.exe' for the sake of windows guys who may not realize that filename extensions really mean nothing in unix land).

I don't think the use of little helper apps should determine a frontend as one having a multi-process design. We should clarify the definition.

2. I don't think that 3rd party plugins count as features. I think they can be listed, but it must be specified as "supported via 3rd party plugin" or something of the sort like you suggested.

**tripzero** · 09-23-2009, 08:30 PM

Originally Posted by malcom2073

But they don't have to, I don't think the line should be drawn at what's shipped with the product, so much as what's considered supported. There are some frontends that ship with third party plugins, can you REALLY consider them to be features if they aren't developer supported?

I think if the product ships with 3rd party plugins, that implies support. I would think it extreme bad-practice to ship plugins with your product that you don't support.

**justchat_1** · 09-23-2009, 08:36 PM

Originally Posted by kev000

I don't think the use of little helper apps should determine a frontend as one having a multi-process design. We should clarify the definition.

Well my thinking on this is if you embed an external application, and it runs an application to complete a task...you no have 3 processes all communicating to complete a task.

Its certainly not multi-processes in the well designed sense but it is multi-process.

I think if the product ships with 3rd party plugins, that implies support.

Well yes in the loose form of the definition. But shouldn't the actual code side of things factor in here?