frontend classification

kev000 · 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:

Quote:

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:

Quote:

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.

kev000 · 09-23-2009, 08:13 PM

Quote: 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

Quote: 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.

kev000 · 09-23-2009, 08:16 PM

Quote: 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

Quote: 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?

kev000 · 09-23-2009, 08:28 PM

Quote: 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.

kev000 · 09-23-2009, 08:30 PM

Quote: 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

Quote: 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.

Quote:

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?

kev000 · 09-23-2009, 08:47 PM

I changed the definition for the multi-processed classification. It rules out helper apps and embedded applications that don't have 2-way communication with the other process.

justchat_1 · 09-23-2009, 09:01 PM

Quote: Originally Posted by kev000

I changed the definition for the multi-processed classification. It rules out helper apps and embedded applications that don't have 2-way communication with the other process.

Thats a lot better

chunkyks · 09-23-2009, 10:03 PM

Why does multi-processed stuff have to be two-way communication?

OBDGPSLogger->obdgui is a one-way communication process. Ditto obdgpslogger->something_listening_on_dbus

Anyways. OBDGPSLogger adheres to classical unix philosophy of "one app does one thing, and does it well". So depending on your view, various parts of obdgpslogger could be any of:
multiprocess, pluginable, multi-windowed, monolithic, embeddable.

Throwing my .02 into the discussion, in my world view "frontend" is, by defintion, the bit that users see & clikky. That's what makes it a frontend.

I also respectfully disagree that plugins *must* be dynamic libraries. They could be a number of things: static libraries [obdsim supports plugins via static as well as dynamic linking], lua scripts, or just about anything else. Lacking a better term in the list above, a theme would be a "plugin".

Gary (-;

PS Yeah, I'm just stirring the water, really. I think trying to argue about what defines a "front-end" when everyone has their own intuitive, fairly-similar definition is a bit silly :-D.

kev000 · 09-23-2009, 10:34 PM

Quote: Originally Posted by chunkyks

Why does multi-processed stuff have to be two-way communication?

OBDGPSLogger->obdgui is a one-way communication process. Ditto obdgpslogger->something_listening_on_dbus

Anyways. OBDGPSLogger adheres to classical unix philosophy of "one app does one thing, and does it well". So depending on your view, various parts of obdgpslogger could be any of:
multiprocess, pluginable, multi-windowed, monolithic, embeddable.

Throwing my .02 into the discussion, in my world view "frontend" is, by defintion, the bit that users see & clikky. That's what makes it a frontend.

I also respectfully disagree that plugins *must* be dynamic libraries. They could be a number of things: static libraries [obdsim supports plugins via static as well as dynamic linking], lua scripts, or just about anything else. Lacking a better term in the list above, a theme would be a "plugin".

Gary (-;

Obd-gui is not a carpc frontend though. It's a frontend to the obdgpslogger backend. Think mythtv style in that case. I always considered obdgpslogger as a classical Unix application: one app that does one job really well. In this case, logging obd and gps values.

I agree with you though, there doesn't necessarily need to be two-way, one-way will suffice in certain cases.

Plugins don't need to only be dynamically linked libs. If I implied that, I'm sorry. nGhost2 called any process that communicated with nGhost gave some sort of added functionality a "plugin". The weather plugin is written in python on uses the IPC protocol to draw on nGhost. A plugin can be anything that adds functionality to an existing app.

Quote:

PS Yeah, I'm just stirring the water, really. I think trying to argue about what defines a "front-end" when everyone has their own intuitive, fairly-similar definition is a bit silly :-D

Yes, but remember, we are humans, and humans like to define things for some odd reason... Plus, i'm a sucker for software design theory...