Re: Simple Components 4.12 with MQTT implementation released

[slos <new.stephane.los@gmail.com>]

Le vendredi 15 avril 2016 18:31:00 UTC+2, Dmitry A. Kazakov a écrit :
> 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.
You have read the data sheet too fast. May be you should consider to read it again.
Not only you have OPC UA or MQTT but also on the same medium EtherCAT, Ethernet/IP or PROFINET.
So real time data is exchanged via real time protocols and relevant data for cloud application is exchanged with OPC UA or MQTT.

> 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.
OPC was never designed with this kind of needs in mind.

> 
> >> 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?
You could use Ethernet over EtherCAT.

> > 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.
Please could you give your definition of interoperability?

> 
> >> 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.
So Ada from hardware to application.
All or nothing ? You'll have to endure frustration.

> 
> 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.
Standards may evolve and particularly when the technology is quite young.
We are not talking of the tables of law.
The good thing with software is that it can evolve with the knowledge on the problem at hand.

> 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
This is over simplified.
Actually Gnoga is in use in "Ada for Automation" and I have already thanked you several times for providing Simple Components.
Gnoga allows an Ada application to talk to the browser and provide a GUI to the application.
That does not make the Ada application an application running in the browser.

> 
> > 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.
Other communities have also competent engineers. They don't write their code in the Ada language but that alone does not make their creation a crap.

> 
> > 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?
This is called integration. And the Ada language favors it greatly but may be suffers from a too competent engineers community.

I don't consider myself a competent engineer for having used too much technologies and languages to be an expert in any. I am just a support guy interested in development.

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

BR,
Stéphane