Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Componentize

  1. #1
    Newbie contri's Avatar
    Join Date
    Jul 2003
    Posts
    19

    Componentize

    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

  2. #2
    Maximum Bitrate mushin's Avatar
    Join Date
    Aug 2004
    Location
    SE Michigan
    Posts
    750
    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?

  3. #3
    Newbie contri's Avatar
    Join Date
    Jul 2003
    Posts
    19
    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

  4. #4
    Maximum Bitrate mushin's Avatar
    Join Date
    Aug 2004
    Location
    SE Michigan
    Posts
    750
    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.

  5. #5
    Newbie contri's Avatar
    Join Date
    Jul 2003
    Posts
    19
    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

  6. #6
    Maximum Bitrate mushin's Avatar
    Join Date
    Aug 2004
    Location
    SE Michigan
    Posts
    750
    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

  7. #7
    Maximum Bitrate mushin's Avatar
    Join Date
    Aug 2004
    Location
    SE Michigan
    Posts
    750
    Quote Originally Posted by contri
    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
    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?

  8. #8
    Raw Wave hijinks21's Avatar
    Join Date
    May 2002
    Location
    Albany, NY
    Posts
    1,803
    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

  9. #9
    Maximum Bitrate mushin's Avatar
    Join Date
    Aug 2004
    Location
    SE Michigan
    Posts
    750
    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.

  10. #10
    Newbie contri's Avatar
    Join Date
    Jul 2003
    Posts
    19
    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

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

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

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •