Thread: frontend classification

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

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.

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.

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

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 (-;

Additionally, future posts from me in this thread will contain [possibly veiled] references to Kev000 as an "ugly bag of mostly water".

Heh, heh. "meatsack".

Gary (-;

hey, who you calling "ugly"?

I edited the definition of pluginable in the top post.

Originally Posted by kev000

hey, who you calling "ugly"?

I edited the definition of pluginable in the top post.

How bout "communicates with the front end to enhance functionality"....

That way we eliminate scripts and embedding applications

Originally Posted by justchat_1

How bout "communicates with the front end to enhance functionality"....

That way we eliminate scripts and embedding applications

You mean, eliminate scripts and embedded apps that don't communicate with the frontend?

No I mean to make sure they don't fall under the definition of a "plugin". Embedding a standalone app with no interaction with the host is not a plugin its just re-branding.

Same thing goes for scripts and "helper apps"...No communication-not a plugin