Re: Simple Components 4.12 with MQTT implementation released

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2016-04-15 17:47, slos wrote:

>> But when the middleware is OPC or MQTT you cannot not put it
>> into a device and expect that working.
> Yes you can :
> http://www.hilscher.com/fileadmin/cms_upload/en-US/Resources/pdf/netIC-IOT_Datasheet_10-2015_EN.pdf

It is not a device, it a SBC with an OPC stack in it. We have that too, 
an ARM board with OPC UA server, no problem whatsoever. Anybody can have it.

Now try to sample 8 10kHz channels and subscribe to them through OPC, 
get the data to a PC and log them with time stamps and no losses.

>> This is the reason we must live
>> with EtherCAT, ProfiNET down there, which are nightmare to any system
>> integrator.

> That is not the case. Those standard protocols are designed with
> lots  of goals, among them performance and interoperability.

How does EtherCAT operate with other protocols?

> They allow multiple vendors to propose products fitting well
> together  and it works pretty well since years.

Clearly, any protocol is interoperable with itself. This is not 
interoperability, when multiple vendors can implement it, IMO it is 
openness.

>> That defeats the very idea of a middleware.
> I don't see why. The middle of what ?

A middle between an application logic and the 
devices/actuator/sensor/data source logic.

The idea of middleware is to be able to develop applications 
independently on the actual hardware and its configuration directly in 
the terms of the problem space's variables.

> Architecture is made with layers and middleware can sit between any two of them.

Yes, that is the application on the one side and data 
acquisition/control hardware on another. The latter naturally includes 
networking and other distribution means. A middleware that is not a 
distributed one is useless for automation.

>> The ugly protocols like XML, HTTP, OPC etc only
>> hinder developing of safe and efficient systems.
> Yes but they allow interoperability, and the web and talking to each
> other whatever browser or platform we use.

This, again, is not interoperability. Nor it is portability, you 
probably meant.

Web application are *NOT* portable. They require a specific platform 
called browser.

If web "standard" were true standard we would already have hardware 
browsers instead of software emulators like Firefox.

But the "standard" is so bad that it requires permanent patching of the 
"platform", which prevents developing to make it real hardware.

An Ada program is portable in the sense that you can translate it into 
the machine language of the target platform. Even if the platform is web 
and machine is browser! See gnoga

> I think one of the problems of Ada community is a kind of
> sectarianism or elitism.

Ada community consists of competent engineers, that shapes it this way. 
Is it a problem? Maybe it is, but I prefer this problem to others.

> I agree that Ada has great qualities and could be used with huge
> benefits in most applications but there is an ocean of already available
> stuff that is not written in Ada and work anyway.

Yes, but that does not make it better than it is. If we only used 
available stuff, why would we have to program anything?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de