Interfacedefinition for Car-PC Module

Hello,

first i want to say that i really like the idea of frodocom (as far as i understood it :)).
IMHO i think if more developers will use this network and make modules for it, everybody will be able to "design" its own softwarecollection for his carPC like zorro shows in his graphic.
So everybody could choose if he wants a player based on winamp or on mediaplayer and so on.
but the mainproblem is, that we first had to arrange about a general interface description for each module??? or am i wrong?
lets say u have a module which handles the skin, also u had a module which plays music, one for video and one for gps. where does each module know what to do or maybe the skin-module know, what command should be send to what module???
so my idea is to have a definition for each module-type to be interfaced and which type this module is. F.e.:

Modultype: AudioPlayer
Functions: PLAY; STOP; PAUSE; NEXT; PREV; FASTFWD; FASTRWND; SHUFFLE; REPEAT1; REPEATALL; .....

Properties: CUR_SONG_TITLE; CUR_SONG_GENRE; CUR_SONG_ARTIST; CUR_SONG_LENGTH; CUR_SONG_POS; REPEAT1; REPEATALL; SHUFFLE; ALBUMART; ....


ModulType: Mixer
Funcions: MAINMUTE; MAINVOLUP; MAINVOLDOWN; LINEINMUTE; LINEINUP; LINEINDOWN; MICMUTE; MICUP; MICDOWN; PRESETNEXT; PRESETPREV; ...

Properties: MAINVOLLEVEL; MAINMUTE; LINELEVEL; LINEMUTE; CURPRESET_NAME;...

i hope u understand what i mean???

please tell me if i'm totally wrong, but i think if we had such a definition, it will be much easier to the developers to write a module for frodocomm??

bye, hematec

Yes, that's right.
I rather would do a recommendation for the most common commands than to define anything.

Also, I'd prefer XML commands because they are more versatile and powerful.

Can you please explain why XML commands are more versatile & powerful?

What advantage does XML give in this case?

Sure.

First of all it's a standard and it's very strict.
As a programmer you don't have to care for i.e. what separator is used to group sequences. Maybe you know that situation where people tend to separate lists with various charaters. For example:

Code:

---

CUR_SONG_TITLE; CUR_SONG_GENRE; CUR_SONG_ARTIST; ...
CUR_SONG_TITLE|CUR_SONG_GENRE|CUR_SONG_ARTIST|...
CUR_SONG_TITLE,CUR_SONG_GENRE, CUR_SONG_ARTIST,...

---

If you do it "the old style" you either have to define the way you do it (what separators you use) or you have to take into account every possible "flavour".

The other reason is it's far more "human readable". The sample above in Xml could be:

Code:

---

<CurrentSong>
  <Title>...</Title>
  <Genre>...</Genre>
  <Artist>...</Artist>
</CurrentSong>

---

Even thought it's more complex, you can read it very easy. Because of it's hierarchical structure, the subordinated tag can be the same even if the parent changes:

Code:

---

<NextSong>
  <Title>...</Title>
  <Genre>...</Genre>
  <Artist>...</Artist>
</NextSong>

---

Instead of:
NEXT_SONG_TITLE, NEXT_SONG_GENRE, NEXT_SONG ...

Not only the understanding of the structure is easier but also programming it much easier.

Most languages come with libraries to handle Xml. Therfore you don't have to do it yourself (which is very complex if you try to get along with the specification). By utilizing XPath you can retrieve each Tag / Attribute with only one line of code.

Another sample:

Code:

---

<Car>
  <Chassis>
    <Axis count="3" />
    <Wheels>
      <Wheel position="front_left" count="1" />
      <Wheel position="front_right" count="1" />
      <Wheel position="rear_left" count="2" />
      <Wheel position="rear_right" count="2" />
    </Wheels>
    <Brakes>
    </Brakes>
    <Bumpers>
      <Bumper position="front" size="big" />
      <Bumper position="rear" size="real_big" />
    </Bumpers>
  </Chassis>
  <CarBody>
    <RearviewMirros>
      <ReaviewMirror position="left" />
      <ReaviewMirror position="middle" />
      <ReaviewMirror position="right" />
    </RearviewMirros>
  </CarBody>
  <CarData>
    <MaxSpeed units="mph">200</MaxSpeed>
  </CarData>
</Car>

---

Even if I don't tell you a word what it's about, you'll know.
And also, because of it's structure you'll know, that it might not be the best idea to mount a bumper on a rearview mirror ;)

One option that is barely used but also usefull, you can apply schemas to every Xml and define restrictions. Schemas will defines what's allowed and what not. So you're able to check the validity of such a Xml document when the document is loaded. Typos can be determined very quickly.

Sure, Xml can be an overkill if you just want to send/receive a temperatur of 33°. You can send a normal string like:

Code:

---

Temperature=33

---

This is very easy and also human readable... but... is this from the inside or from the outside... and ... whats the unit?
Maybe, because we're talking about a FrameWork that can be used in every car on the planet, this makes more sense:

Code:

---

<Temperature type="engine" unit="Celsius">33</Temperature>

---

Eventually, it's all up to you and your personal taste but I think if you want to join programming such a FrameWork, you will save a lot of time by using Xml. ;)

I personally find XML a waste of time because I find I can do it all quicker in other ways. A standard is a standard, you don't have to worry about the delimiters because they've already been decided. XML just has a flexible structure and very big delimiters. All you gain by having a flexible structure is the ability to pass different chunks of data through one interface - but you still have extra processing to do to determine whether the data is valid or not.

XML bloats data. Bloated data costs more to transfer across a network, and/or takes more memory to store, and/or takes more time to process.

Lets say I want to put together a system that lists various temperatures around the car. I can list 33, 22, 71, 12, 46, 0, 23. That's a whole 25 bytes. I could even store them as raw byte values, and squeeze it into 7 bytes. Or I can set about creating entire definitions for what I already know. Your example above would take more than twice my entire dataset. Multiply that by my 7 values and your data is suddenly 14 times bigger. Or 50 times bigger if you favour a raw set.

In my byte example, you don't have to deconstruct any textual human-readable data. You just get the values from their locations. XML is only human-readable because it's represented in ASCII. But why does it need to be human-readable when we can all read bytes?

If it works on XML then it works on XML. But I do think XML is far too often just used for the sake of using it. Even Business-to-Business data transfers have to be coded up in instances where XML is being used to make things "easier." An XML DTD is just a document that tells you where things go. It doesn't tell you where to get them from for any other system. And that other system is unlikely to tell you. All the transformation & mapping still has to be done. It just makes something "human-readable" where people don't need to read it.

I agree, Xml bloats data.

But what's about let's say IDL? You write a program that eventually is pure machine code and then you put tons of (human) readable information, only for the purpose that any programmer that will use your program knows what interfaces you've implemented. This is wasting of space too but do you complain about? I'sure you don't because it's a benefit for you.

So is Xml. The documentation of the document is contained in the document itself (if it's made right).
And that's the point: Xml is not made to save space, it's made to bring light into the darkness of proprietary data formats (which btw. a dataset of 33, 22, 71, 12, 46, 0, 23 without a doubt is) and to make interfacing data easier.

Since FrodoComm was build to be a central instance that is dispatching messages between plugins, you need something that everyone can deal with without the need of understanding and handeling hundrets of proprietary data structures. Therefore, FrodoComm supports only text messages, no binary formats at all.

BTW: DTD (which is not longer used) doesn't tell you where to get the data but XLink does. It's always a question about the right combination of technologies ;)