Announcement

Collapse
No announcement yet.

frontend classification

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • frontend classification

    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
    Former author of LinuxICE, nghost, nobdy.
    Current author of Automotive Message Broker (AMB).
    Works on Tizen IVI. Does not represent anyone or anything but himself.

  • #2
    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.
    "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
    RevFE
    My Shop

    Comment


    • #3
      Originally posted by malcom2073 View Post
      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.
      Former author of LinuxICE, nghost, nobdy.
      Current author of Automotive Message Broker (AMB).
      Works on Tizen IVI. Does not represent anyone or anything but himself.

      Comment


      • #4
        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.
        openMobile - An open source C# Front End (why choose openMobile?)
        - Always Recruiting Developers -
        Like what you see? Donations are always welcome

        Comment


        • #5
          Originally posted by kev000 View Post
          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.
          "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
          RevFE
          My Shop

          Comment


          • #6
            Originally posted by malcom2073 View Post
            Ah! therin comes the wonderful term: "Developer Supported" vs "Third Party" plugin/feature.
            Usually developer supported plugins/features ship with the product.
            Former author of LinuxICE, nghost, nobdy.
            Current author of Automotive Message Broker (AMB).
            Works on Tizen IVI. Does not represent anyone or anything but himself.

            Comment


            • #7
              Originally posted by kev000 View Post
              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?
              "stop with the REINSTALLS, what do you think we got some lame-o installer!!!" - mitchjs
              RevFE
              My Shop

              Comment


              • #8
                Originally posted by justchat_1 View Post
                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.
                Former author of LinuxICE, nghost, nobdy.
                Current author of Automotive Message Broker (AMB).
                Works on Tizen IVI. Does not represent anyone or anything but himself.

                Comment


                • #9
                  Originally posted by malcom2073 View Post
                  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.
                  Former author of LinuxICE, nghost, nobdy.
                  Current author of Automotive Message Broker (AMB).
                  Works on Tizen IVI. Does not represent anyone or anything but himself.

                  Comment


                  • #10
                    Originally posted by kev000 View Post
                    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?
                    openMobile - An open source C# Front End (why choose openMobile?)
                    - Always Recruiting Developers -
                    Like what you see? Donations are always welcome

                    Comment


                    • #11
                      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.
                      Former author of LinuxICE, nghost, nobdy.
                      Current author of Automotive Message Broker (AMB).
                      Works on Tizen IVI. Does not represent anyone or anything but himself.

                      Comment


                      • #12
                        Originally posted by kev000 View Post
                        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
                        openMobile - An open source C# Front End (why choose openMobile?)
                        - Always Recruiting Developers -
                        Like what you see? Donations are always welcome

                        Comment


                        • #13
                          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.
                          OBDGPSLogger, for logging OBDII and/or GPS data
                          OBDSim, an OBDII/ELM327 software simulator
                          mp3car forums: obdgpslogger, obdsim

                          Comment


                          • #14
                            Originally posted by chunkyks View Post
                            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.

                            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...
                            Former author of LinuxICE, nghost, nobdy.
                            Current author of Automotive Message Broker (AMB).
                            Works on Tizen IVI. Does not represent anyone or anything but himself.

                            Comment


                            • #15
                              Plugins don't need to only be dynamically linked libs. If I implied that, I'm sorry.
                              Pluginable
                              Can extend functionality via dynamic libs.
                              Heh, heh.

                              I suggest updating the top post with the improved lexicon

                              we are humans
                              Speak for yourself, meatsack.

                              Gary (-;
                              OBDGPSLogger, for logging OBDII and/or GPS data
                              OBDSim, an OBDII/ELM327 software simulator
                              mp3car forums: obdgpslogger, obdsim

                              Comment

                              Working...
                              X