Programming Interface standardisation?

**madkat** · 12-03-2005, 12:42 PM

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, 01: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, 01:57 PM

Thanks

**FMode** · 12-30-2005, 05: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, 06: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, 06:57 AM

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.

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, 07:58 AM

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

**madkat** · 12-31-2005, 08: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, 08:11 AM

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 !

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

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, 09: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
.Net FrontEnd
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 ?