contri

Hello,

I have been reading the forums for a long time, but written very few posts.
I have in mind writing some software for my car PC, without reaching the levels of MediaEngine, etc, but more focused to my specific configuration.

I planned to write some simple parts, and make them talk a common language between them. Probably "components", see subject, is not the best word, but I thougth it was sort of.

With some parts there is no problem: for example, playing mp3 using winamp, accessing winamp functionality with the Windows calls WA provides.

But other parts, like using a program for under/overclocking the board according to heat / stress can't be done. Because that program doesn't expose a way to get that information or receive a command

This takes me to think that maybe if we had a list of components, and just choose the right ones for our setups, development and customization would be faster. It could be something like

Layer 1: HW functions. No resource collision controlling, etc. This layer talks to the next one. It would just be functions like play, stop, loadInPlaylist, etc, etc.

Layer 2: Resource planing. This layer should decide how to filter / process / select events and info from the layer 1. There will always be problems like "I'm playing MP3 and then I receive a phone call via BT, which I'd like to listen hands-free". Resource sharing is necessary evil, unfortunately.

Layer 3: GUI, if you want to have it. In my case, I'd like a 20x2 blue LCD. Maybe you prefer the Liliput way. This layer would just process the events and info from Layer 2.

Ok, If you have reached these point, maybe you think this seems obvious, etc. Just another Layer-approached application. But, the point of all this is to ask you:

Would it be interesting to create and share the components I said? That way would speed up the testing of functions, because instead of learning SAPI 5 functions for Speech synthesis, I would simply call the "say" function of the talker "component". The same can apply to GPS, etc etc.

The advantages I see are mainly: more personal set-ups (Ok, you'll need to wrote some code), knowledge sharing (maybe you know how to underclock/overclock the boards and decide to add the communication part it didn't have before), and quick testing & development.

Well, sorry for the long post. I wait your opinions. I know this is near the philosophic part of programming, but if we take it to real-world examples, I think it can be useful


Contri

MP3Car.com

 

mushin

Sounds like you're talking about making a fairly comprehensive framework which provides a very high level API to the end user. Or maybe you want just a loose collection of API's that play by the same rules? It would certainly be interesting, and done right might provide a mice basis for allowing people to leverage each other's work.

That said, what you're proposing here is hardly trivial. Were you planning on taking the initiative, or is this another "hey, it'd be cool if someone did..." idea that's inevitably easier said than done?

If you do go forward with it, I can provide C APIs for mp3/ogg playing (not winamp-control), and HD44780 based character LCD output, for now. Heck, maybe some people want it regardless?

contri

I think it would be more like a loose collection of API's that play be the same rules. Just bare functionality. To make them follow some rules would be the difficult part if everything had to be specified, but I don't believe in so much specifying: instead, I think that everyone should be free to set the function names and create the function he thinks he needs. If you need some more functionality, add your functionality to the code or start from scratch another similar component. This can lead to "simple mp3 player" or "sophisticated mp3 player with media library incorporated", don't know. Developers choose the component they prefer and build their soft on top of this coimponents, making them work together.

As you can see there in nothing to lead. It's just to add a standard interface to developments. Defining this interface, or communication path between components is the non trivial part, although I have done some tests in this field which are allready working pretty well.

I see you have worked or have some HD44780 LCD controller code. Imagine how easy could be to me to take your component and send it an order to display some text like winamp component's song title. If you didn't share that piece of soft, I would have to start reading the HD44780 developer information and crete my own. Why? Because the people who sells LCD don't give you a soft that can be controlled from outside easily. (Note: I am not a LCD guru, so I don't know if the LCD soft I say exists.).

Extend this example if whoever develops a soft for a concrete piece of hard or soft shares it as a component. I would do so with the devices I'm planning to program.

I don't pretend to rewrite everything, but get what is already working, tested and coded by excellent programmers. If it can be interfaced don't rewrite it unless it doesn't do what you want.

I know I will forward this way with my development. This will improve my reusability of code among projects and scenarios, like changing the programming language, etc.

Contri

mushin

Without a formalized inter-component communication system, along with some general management code, you're always going to have to write all of the glue code between all of the components. You won't be able to say, "I want a system that loads the Mp3 and GPS components, and outputs to this GUI system", and just have it work. And then later decide you like this new GUI someone made better, so just swap it in. That's how a true componentized system should ideally work, but you're going to need a standard interface, or better a standard method of exposing an interface, to do that.

If you have the developers writing whatever interface they want, well, we basically have that situation now. You can find all sorts of free or open source code on the web that alleviates you from having to reinvent the wheel. Sourceforge is an excellent example.

Now, I certainly wouldn't be against having a section in the forums where people can post libraries relevent to carputer software development. In fact, that sounds like an excellent idea.

contri

The glue part must be rewritten every time: Yes. But that's not bad. This glue part is something you'll want with a certain behaviour, while I can prefer another one, i.e giving priority to some events on others, etc.

All we need is, as you define it, a formalized intercomponent communication system (FICS, sounds nice). And everybody to agree on that, so every component "talks" the same way.

No standard interface. Or, at least, I won't the One who dares to standarize the functionality of common components. That could be a great battle. Instead, as I told you, let everyone program what they think is worth. In its own way. Just that, if they want to share their work, they can add this FICS part to "talk" in this standarized way. Yes, if you change a component, you'll have to repair the glue. But trying to define a common-universal interface for music playback capabilties would lead to and endless battle, far longer than modifying the glue part

What we already have now, is: Some projects let you interact with them, some have scripting capabilities, other accept plug-ins, other accept windows commands, etc. And others don't accept anything. There is no easy way to join that. I know some sourceforge projetcs which can be categorized in the categories I said.

I fully agree with you with in the section with libraries / programs which let to be programatically accessed, like winamp, etc... relevant to carputers. Do you want to start the thread?

Contri

mushin

I think one or both of us is misunderstanding the other

When I say you need some minimal standard interface, I'm not saying we need to define what a mp3 module does, or what a GUI module does. Definately no attempts to standardize functionality of components! What I am saying is, for the components to communicate (and not require you to be interpreter) you need to require implementation of at least something like

do(string command)

that tells a component to do something. Because the implementer of a component doesn't know what other components it might be talking to, there's no way to communicate unless there is some standardized interface by which to do it.

Now, there's nothing that says a mp3 module must support a do("pause") command or whatever; that level interface is probably what you're saying we shouldn't dictate? With that I completely agree.

But when you get down to it, the "FICS" requires some standard interface in order to work

mushin

I think we're better off having a mod do it, provided that they agree it's a good idea. That way it could be made sticky, and also help keep out unneccessary chatter from the thread. Mods? What do you think?

hijinks21

if anyone is open to doing an open sourced "carPC engine" i'm all game to help as long as its in C++. I'm looking into doing something when i finish a few projects of just putting together a engine that will handle plugins. Don't like the standard MP3 plugin.. so use the other 3 that people have made.

I don't do C# or VB so don't even ask I'm a linux person that accepts most people will still want to use windows.. even if i create a carpc app that will drive for you

__________________
'98 Explorer Sport
http://mp3car.zcentric.com (down atm)
AMD 800mhz 192megs RAM 60gig hard drive 9 inch widescreen VGA
80% done

mushin

I fellow C++ coder! I was afraid I was surrounded by VBers! (j/k )

Still, any libraries along the lines above probably should have a C interface, as just about any language is capable of using it without too much difficulty.

I would be happy to contribute to a open source carPC engine, including helping architecting it. I've never been involved in an open source effort before, but this seems like a good place to start as any.

contri

You can count me in the non-VBers side

I know C++, but have little experience with Windows API or MFC. I prefer Java for programming, and C++ for the things imposible in Java


Don't stick with a language: The interface could be something language independant: Like sockets, which can be opened in any language. This way, you and hijinks21 can program in C++ and I continue with my Java.


Just to clarify this:

Imagine I make a mp3 component.
I admit the following commands:
-play
-pause
-stop
-pause
-next
-previous

And I send events out when happens something I think relevant.
- song changed

Nothing more. And with these names. So, I release this component. You'll need to have a look to the commands /events it admit. But, later you can send a "do(play)" command, etc. to it.

Maybe you or anyone else creates another one. More functionality, and he hates or don't find appropiate the "pause" name. Ok, he can name it "wait until next order". To use this component you would need to change any "do (pause)" to "do(wat until next order)".

This gives freedom in the name writing, it's me, the one who wants to reuse the component who has to know which names to give. Giving this freedom alleviates the tedious labour to verify names for consistency, etc, making the addition of the "FICS" so-to-speak interface easier, just a sending/recevieng commands thru a channel.
I don't see anything to standarize, but the channel. The commands supported depends on the necessity (which is mainly what moves the programmers) the programmer had when coding that.

I don't think this can become an engine. Components won't be plug and play, because there will be some intelligence needed to remap names and readapt functionalities

It certainly shortens development times. No need to dive in other's code to isolate what you need and add it to your project. Just call the function thru the communication channel

Contri

hijinks21

ya i've pictured it the same way.. just have the "server" sitting there reading a socket.. say commands get passed in a xml string for standards sake. So a user can code a plugin in whatever language they want.

We were going down this path with Xcar but ran into some design issues. Like how do you skin it?

__________________
'98 Explorer Sport
http://mp3car.zcentric.com (down atm)
AMD 800mhz 192megs RAM 60gig hard drive 9 inch widescreen VGA
80% done

mushin

Contri, we're in agreement. Like you said, you need to define that channel through which components speak, and that is, well, a standard interface . That's all I was getting at.

What we have here is basically an agent system.

I agree, that in itself would not be an engine. While an engine might utilize a system like that, it's going to be an entirely different discussion.

I would see something like skinning implemented at the GUI component level. How (or whether) skinning is done would be left up to the GUI component. Or am I missing something here?

Passing around commands is easy, but bigger chunks of data might get problematic. How would a nav system work? A GPS component might output coordinates, which are input to a map component, which would output.... large bitmaps? At fairly high refresh rates? When things are highly decoupled passing things around like pointers get very tricky (and for that matter, many languages don't support pointers.) Having the mapping module draw directly to screen would be a solution, but then we have a whole can of worms with resource sharing.

Or maybe a naivgation system is simply out of the scope of what we can do with our FICS, and it would still have to be implemented by a parent app. At least it'll be easier, since you can leverage the GPS module. After all, we don't need to be able to construct a complete system. The whole point was to make it easier, right?

I forget if I had a point with this post I guess I'm just contributing my thoughts.

contri

Mushin,

Yes, skinning can be left to a GUI component. But, this GUI one must know (so, you have to program it) according to all the components it has below. Changing/adding a component will make necessary changes in the GUI Component, due to the new / name changed messages flowing. So, a GUI would be tied to a set of components or configuration. Once this set is fixed, skinning is just a matter of changing bitmaps, etc. to respond to the same messages. The problem of a flexible set of components without touching the GUI is quite complicated, if not impossible.

I don't think big chunks of data are necessary to get passed thru this communication channel. We would have to fight with the resource sharing. But I don't think it's so hard (even though things become 10x more complicated when you are at work and see all the details and problems). Sound is always shared, there are many sources of sound. MP3, cd player, FM radio, Text-to speech, Bluetooth mobile, etc... There is a need for some resource controlling, to assign it to a source, and communicate to a component it has lost the screen or the speakers. Doing so avoids calculating a map that won't be shown, for instance. Or imagine that the GUI part, which knows the GPS is on the screen or not, sends a command to the Map component to draw the map, which then asks the GPS position to the GPS component...

Out of scope? NOOOOO Decoupling leads to problems, right, but I hope it also bring some nice features.

Contri

mushin

The difficulty of resource sharing is going to vary alot with the resource. Sound is almost trivial, since sound mixing can and is done at the driver/HW level. All the components can merrily send sound to the output device, and it'll work. Graphics... I suppose it'd work if all things like map graphics were done in non-framed windows, with regioning if the graphics aren't rectangular, but man, that seems like such a hack.

Fortunately, I doubt many components would need to output directly to screen. Most would just produce low-bandwidth data streams that can be piped to controls in the GUI module. The only ones I can really think of are mapping and cameras, though of course you want to leave it open.

Moving right along in reverse order....

Obviously the GUI component would have to be tailored at some level for the components below it. But the developer of the GUI component shouldn't need to know exactly what's going to be used with it. I see two approaches to this:

One, even though we are not requiring any component to support any specific interface (beyond the communication layer ), a component might declare itself to be compatible with other components that meet some spec. After all, I imagine most like components would probably support similar interfaces. A de facto standard may emerge, even if we don't impose a de riguer (sp?) one.

Alternatively, a GUI could expose a bunch of inputs, and it would be up to the end user (perhaps with some common-use examples) to tie the outputs from components to appropriete inputs in the GUI, as well as directing the GUI where to display it, etc. In this sense, the GUI would be more of a GUI kit.

I think either method will decouple most of the heavy lifting for the GUI from the need to customize the GUI to function as an appropriete output conduit.

MP3Car.com