Programming Interface standardisation?

madkat · 12-03-2005, 11:42 AM

Just a thought, peeps...

.Net and ActiveX DLLs can have really complex methods etc. But why don't we get together some ideas on standardised methods & properties for plugins?

Then those of us who do code can integrate other peoples libraries quickly & easily.

So, with a GPS Input Plugin you could get standard coordinate data. Then that data can be used in a call to, say, a Speedometer plugin *and* a mapping plugin.

Then you get to choose whichever speedometer plugin you find most accurate, and whichever mapping/routing plugin you like most. And if you don't like any, you can write a new one and share it.

A routing plugin's waypoint output could even be used in conjunction with a proximity plugin, which in turn causes a speech synth to give the next instruction. Even the speech system could be a plugin, which just calls the standard MS speech stuff or else outputs wavefiles.

zorro · 12-03-2005, 12:38 PM

If you're a programmer, this might be of some value for you:
http://www.mp3car.com/vbulletin/fp-frodocomm/

madkat · 12-03-2005, 12:57 PM

Thanks

FMode · 12-30-2005, 04:55 AM

What you are saying madkat is a must for every coder IMHO...
But people feel great if they can reinvent the wheel again and again....

zorro:
Right way - but unhandy as it uses "late binding" of all interfaces. Strong-binding makes programming more easier - the object you import and use reveals it methods (Play, Open, ....) - if the names are choosen wisely you don't need a manual

Why isn't PhoneControl a .NET Assembly which can be imported (into Frontends) ?

And this is my Proposal (in VB.NET but as it is .NET it doesn't care that its VB) of a modular Frontend based on components:
http://netsh88.hades.net-build.de/fm...I-Frontend.zip

zorro · 12-30-2005, 05:09 AM

Strong (or early binding) requires that your compiler knows about the objects you will use and therefore you have to include them into your project.
Thus, you'll never be able to "attach" a new plugin after the main app is on the market without changing the main app, which turns the term "plugin" to a farce.
The right way is to declare interfaces, which couples late binding and "easier programming" - whatever this is supposed to mean - but if you don't know yet what interfaces you'll need in the future, you have use the simplest and most powerful - and that is Xml.

PhoCo has an interface for other applications but it's based on TCP socket, because not all programming languages can handle .NET assemblies. Maybe you have recognized most frontends here are VB6 based - think about.

madkat · 12-30-2005, 05:57 AM

Quote: Originally Posted by zorro

Strong (or early binding) requires that your compiler knows about the objects you will use and therefore you have to include them into your project.
Thus, you'll never be able to "attach" a new plugin after the main app is on the market without changing the main app, which turns the term "plugin" to a farce.
The right way is to declare interfaces, which couples late binding and "easier programming" - whatever this is supposed to mean - but if you don't know yet what interfaces you'll need in the future, you have use the simplest and most powerful - and that is Xml.

No, I think XML is just a pain in the arse. Certainly late binding is the ideal method for plugins. As for .Net/COM, .Net 2 IDEs will happily create assemblies which expose themselves to COM. And VB.Net 2005 will allow you to late bind a library, then it will automatically probe it for its interfaces and make them visible.

Quote: Originally Posted by zorro

PhoCo has an interface for other applications but it's based on TCP socket, because not all programming languages can handle .NET assemblies. Maybe you have recognized most frontends here are VB6 based - think about.

Yes, so writing .Net/COM assemblies is the perfect solution. Further, VB.Net 2005 is a *FREE* download from the Microsoft website, along with all the other .Net 2 languages.

zorro · 12-30-2005, 06:58 AM

Well, do whatever you want, I don't care.

madkat · 12-31-2005, 07:04 AM

I think perhaps people didn't fully explore the capabilities of the technologies already at their disposal before deciding how to tackle the problem.

FMode - I'll take a peek at what you've got when I'm back home tomorrow and hurl any feedback in your direction. Maybe we can kickstart something here.

FMode · 01-04-2006, 07:11 AM

Quote: Originally Posted by zorro

Strong (or early binding) requires that your compiler knows about the objects you will use and therefore you have to include them into your project.
Thus, you'll never be able to "attach" a new plugin after the main app is on the market without changing the main app, which turns the term "plugin" to a farce.

I don't think so

Download my proposal - all components are compiled...
Start the MainContainer.Exe and notice WMP in the main window
Now replace mediaplayer.dll with the one from "MediaPayer(Winamp)" and start MainContainer and now you don't see WMP anymore...
Bot DLL's implement the same interface...

This works and this makes .NET so cool !

Quote: Originally Posted by zorro

The right way is to declare interfaces, which couples late binding and "easier programming" - whatever this is supposed to mean - but if you don't know yet what interfaces you'll need in the future, you have use the simplest and most powerful - and that is Xml.

How is this handeled in VS ?

Interface-versioning is a central (and the only) problem IMHO but it could be solved.
I have defined my FMRadioHAL as version 0.1 - means should not reach any enduser.
1.0 will contain Fieldstrength, Volume, Frequency, RDS ...
Frontends can implement their Radiopart (or better their Radioplugin!) with FMRadioHAL - so a analogue Fieldstrength display with a moving pointer will be created in the Frontend..
Now someone may build another radiohardware which also delivers "multipathstrength" so this guy can deliver this value to the frontend with the Function "AnyFunction" (which is now some sort of late binding!). He can now create his Frontend which works with all FMRadioHal's AND his late-binding "mp-strength"....
In version 2.0 of FMRadioHal those late-bindings will be moved to early-bindings as this is much nicer to handle. (from FMRadio.AnyFunction("MPXStrength","134") to FMRadio.MPXStrength(134))

Quote: Originally Posted by zorro

PhoCo has an interface for other applications but it's based on TCP socket, because not all programming languages can handle .NET assemblies. Maybe you have recognized most frontends here are VB6 based - think about.

Look at my FMRadioHAL - it shows how to use one DLL as .NET Assembly *and * as COM Object (easy).
IMHO VB6 is not suitable for larger programm's as it lacks of multithreading. (I know what i am talking about as I worked for a company which had a large programm in vb lets say: 10classes, 20forms, 10 modules - a little bit larger the Roadrunner).
.NET gives also the chance to be language independend... so it should be used.

to Phoco:
BTW: nice piece of work...
I would like to pull the Phoco ActiveX onto my Telephone-Form.... An event would be nice if the telephone rings (so I could do a Mediaplugin.Volume=Mediaplugin.Volume-something)...

FMode · 01-04-2006, 08:40 AM

okay guys back to .NET ...

it looks like there is some .NET programming effort going on:
http://www.mp3car.com/vbulletin/other-cool-front-ends/66156-new-open-source-front-end.html#post709979
http://www.mp3car.com/vbulletin/other-cool-front-ends/61719-net-frontend.html
and yes also Centrafuse...

Can we join our forces to build up a standard main programm which includes the functional components like navi, media, radio, phone as plugins ? We are using .NET and this makes this a lot easier as it ensures language indepedence.
(Personally I hate C

)

Benefits:
- wheel is invented ONCE which is IMHO enough

- you are not happy with the media plugin ? Yeah write your own !
- This Mediaplugin (coder1) rules and that Radioplugin (Coder2) is cool ? Yeah just use it

- spend time writing a "engine superduper control" (wahtever) plugin instead of writing the 1023267. mediaplugin

You are a commercial developer don't want to reveal your source ? than don't do it

- (chances are high that I pay for your software to replace your mediaplugin with my own because I like it more). Surely you can't release a Fontend with free components from others BUT your customers have more selection and this makes YOUR Frontend more attractive !

This "componentisation" of the Frontends is something like the desktop of the home-PC in the car. Exe's which are running themselves on the Desktop - but this concept is not suitable for cars. Excel doesn't need to tell Browser something. But the navigation-part has to tell the mediapart to be quiet as an driving insruction has to be announced.

To sum up:
We need a free-source-open main-container with as much defined plugins as possible. This container should be absolute "stupid" and not knowing anything of whats going inside the plugins - he should only manage the communication betweeen the plugins.
My"Proposal" (to start):
http://netsh88.hades.net-build.de/fm...I-Frontend.zip
(see "MainContainer" !)
I like to see YOUR Frontend - if you don't want to release source:
just compile your valueable plugins...

Hello veetid-flux-centrafuse:
I must take a closer look at your plugins...
What about converting "Media", "Radio" and "GPS" to plugins ?

jmbickham · 01-05-2006, 01:22 AM

Actually I very much like your idea. I rate it higher than stuff like "skinning"... that only changes how things look, not how they work (I mean on the UI level not code). Nice for personalization, but does little for expanding the functionality of the frontend or improving the usability.

It's actually something that I have thought of as well... I do think that a "core" program which provides the framework for plug-ins is the way to go. I wish my coding was up-to-speed to actually start developing my thoughts beyond the concept phase. *sigh* Time to get back to the VB.NET and C++ books again...

DeltaFX · 01-06-2006, 03:07 PM

Or one could design really independent apps chatting over a sharedmem structure.

Specimen · 01-06-2006, 06:32 PM

I agree with you guys completely. That is the main reason why I started to write my own frontend. I hated the fact that if some new hardware/software product comes out, you need to update the frontend and bump the version up. That was my main drive to writing my software. For now I’m not willing to release my software to the carPC community yet cause I need to finish the Radio and TV plugins (currently I have plugins for Internet, GPS application embedding, DVD, Video, and MP3 with search features similar to itunes). That will be enough to be useful to most people. My hope is to make my front end scaleable and keep the shell code protected but release the plugins as open source to get people to write better plugins.

I’m not sure when I will release for Beta testing but it is working right now. I’m also writing a skin maker to help create the skins. And yes my front end will support BMP, ICON, GIF, JPEG, TIFF, WMF, EMF, PNG (transperent buttons YAY) and it will also support odd shaped Buttons so buttons aren’t always square and can overlap. As I see a lot of people complaining about that.

I haven’t been advertising my front end much cause I don’t want people to think its vaporware or anything. I’m very busy with my current job and I don’t want people hassling me on when its coming out

. But if you guys have any questions about it, PM me.

If you guys do start to come up with a standard I’d like to put my 2 cents in since I have been working on my frontend for ~ 1.5 years and I ironed out quite a few problems already.

Oh and my frontend is written in C++ and is message based with the plugins. This makes the frontend very fast and robust when interfacing the core program with the plugins.

jmbickham · 01-07-2006, 11:24 AM

Cool. Some of your ideas sound similar to my own... Too bad it's C++. I'd rather stick with .NET. Oh well... either way I'm not entirely up to speed yet to be of much help.

Specimen · 01-08-2006, 12:21 AM

I've written it in C++ cause I don't have .Net studio. but that doesn't matter cause the plugins can be written in almost any language. Basically the plugins are just DLLs so anything that can call DLL functions will work. I did it this way so people could write their plugins in VB, C, C++, or anything else that supports DLLs. So you can use .Net for plugins