Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 25 20:49
    mpostol closed #485
  • Sep 25 20:48
    mpostol edited #485
  • Sep 25 20:48
    mpostol edited #485
  • Sep 25 20:48
    mpostol edited #485
  • Sep 25 20:45

    mpostol on 6.1.1-Alpha

    (compare)

  • Sep 25 20:41

    mpostol on master

    Release new version #485 - Fin… (compare)

  • Sep 25 19:37
    mpostol closed #423
  • Sep 25 19:37

    mpostol on master

    Work out Networking.Gateway2Azu… (compare)

  • Sep 25 19:14
    mpostol edited #489
  • Sep 25 19:14
    mpostol milestoned #489
  • Sep 25 19:13
    mpostol labeled #489
  • Sep 25 19:13
    mpostol opened #489
  • Sep 25 19:04
    mpostol labeled #425
  • Sep 25 19:01
    mpostol labeled #423
  • Sep 25 16:28
    mpostol edited #485
  • Sep 25 16:28
    mpostol edited #485
  • Sep 25 16:07
    mpostol edited #485
  • Sep 25 16:07
    mpostol edited #485
  • Sep 25 16:07
    mpostol edited #485
  • Sep 25 14:09

    mpostol on master

    Release new version #485 - Cre… (compare)

Piotr Szymczak
@Drutol
So it would be up to the end application which provider to use while library would just reference the Abstractions
Mariusz
@mpostol
@Drutol I appreciate reporting this an new issue and adding this proposal. I will investigate it but it seems that now it is hard to make any rapid changes.
Mariusz
@mpostol
@Drutol I have noticed that EventSource is defined in System.Diagnostics.Tracing so it should have been provided on all platform. It seems that if something is in the Standard lib it must be recognized as generic enough. I have used implementation for files, but it is very likely that Azure implementation exists as well for any platform.
Anyway selection of a common tracing mechanism is very important and must be backward compatible because you are not the only user. Now 4.0 is ahead so we can make breaking changes but good reasons must be on table. In this case we must prove that Microsoft.Extensions.Logging.Abstractions is more abstract that System.Diagnostics.Tracing - first we must define how to measure abstraction to make comparison in an objective way.
Piotr Szymczak
@Drutol
Mariusz
@mpostol
@Drutol I completely agree with it would be up to the end application which provider to use while library would just reference the Abstractions. Now the library depends on the NETStandard.Library only and It seems we should keep it intact.
Piotr Szymczak
@Drutol
Hmm, I understand that the less dependencies there are the better. Not quite sure how we can go around it though... like with CommonServiceProvider
EventSources are "nono" in my opinion anyway as right now they are enforced logging solution for end application. And as it appears not every runtime supports them
Mariusz
@mpostol
@Drutol we have two issues for now so lets go step by step.
  1. EventSource- Report new issue related to EventSource and collect all your findings and proposals. It is good starting point for further investigation and decision making. Lets do nothing with your application for now. We can state that this feature is not available on mono and that's all. Let me know how it works for you. We should also check the feature against official .NET Standard compatibility table.
  2. CommonServiceProvider if it is supported by the Autofac you should only make sure that you have registered all contract providers I need and it can be marked as fixed as far as I follow this issue.
Piotr Szymczak
@Drutol
Okay, so what other providers do you require to be registered in CommonServiceProvider? I already have there things like UDPMessageHandler and the other 3 implementations I forgot the names of (config, bindings).
Mariusz
@mpostol
@Drutol It seems the ITraceSource is needed for now.
Mariusz
@mpostol

@Drutol Let me return to portability issue in context of the EventSource type, because it is important for this project. EventSource is used in many assemblies and also external projects. It has been assumed that it is main tracing diagnostic data source. As I understand you have not composed it because of portability issue. There is official compatibility table:

.NET Standard Versions

How this table relates to your findings ? I will appreciate your comment. Main assumption for the project is that the library based on .NET Standard 2.0 is portable.

Piotr Szymczak
@Drutol

While https://raw.githubusercontent.com/dotnet/standard/master/docs/versions/netstandard2.0_ref.md does indeed mention the EventSource as a part of .NetStandard2.0 it's worth checking the docs page https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.tracing.eventsource?view=netframework-4.7.2 where they state:

Provides the ability to create events for event tracing for Windows (ETW).

I was browsing the https://github.com/dotnet/corefx repository and I've found inconsistencies when it comes to this class, with some RuntimeSpecific options.
I've also found this: https://github.com/dotnet/corefx/blob/c8c882c7366f2facfca4c8069de79da477dcf05b/src/System.Diagnostics.Tracing/ref/System.Diagnostics.Tracing.cs where implementation is just dummy one like in Mono. My guess is that runtime specific implementation comes in when on Windows and on other platforms it's just dummy class implemented only to be compliant with the specification.
Being only for Windows it's hardly portable as ETW is only Windows thing. I also personally consider them being very clunky to use, but that's just my opinion.

Mariusz
@mpostol

Do you mean that if an implementation does nothing it is compliant with a specification ? !
If the table says that

Xamarin.Android 8.0 and Mono 5.4 is compliant with .NET Standard 2.0 it means empty implementation ?

Can we prove something like that.

Piotr Szymczak
@Drutol
It's not about being compliant or not. EventSource is for ETW. ETW is only present on Windows. So it's impossible to implement it on other platforms.
At least that's my guess based on the files and docs.
The framework stays compliant but due to the nature of the class its implementation may be impossible.
Mariusz
@mpostol

We can prove that .NET 4.7.2. is for Windows and it doesn't meant that Standard 2.0 is for Windows . I am getting lost.

where you find statement that EventSource is for ETW.

Provides the ability to create events for event tracing for Windows (ETW).
If the underlying mechanism (on the OS side of things) being ETW is not available, how could such class be implemented?
That's what I bet on.
Mariusz
@mpostol

@Drutol I see, but in the ReferenceApplication I am not using ETW, even I am not aware about ETW. It seems that it is just typo copy/pasted from the very beginning. I am pretty sure it has nothing in common with Windows ETW. It seems we must treat the ETW shortcut as a general term. Let me summarize:

  1. If it is in .NET Standard => it must be portable to keep the idea intact
  2. If Microsoft states that it is compliant there must exist an implementation that do something not trivial
  3. In platform dependent implementation we should expect some limitations (e.g. ETW is not supported), but they must be clearly stated in the documentation (do we have something in this respect)
  4. The documentation for .NET Standard should be generic and implementation agnostic, therefore the wording problem should be reported to Microsoft. There are more mistakes, for example Starting with .NET Framework 4.6 - it doesn't make any sense in context of this abstract definition. It seems it is copy/paste problem.

I will appreciate any information referring limitation of the mentioned implementations Xamarin.Android 8.0 and Mono 5.4 - empty implementation should be recognized as an error for sure.

Let me also note that ETW is a sink, but we are talking about the source and the source could be associated with many different sinks. I have implemented the sink as a file (no ETW at all it works on XP) and I know an implementation for Azure again nothing in common with ETW, but in any case EventSource is used as the source.

Mariusz
@mpostol

@Drutol I have reported the problem:

dotnet/dotnet-api-docs#1723

Thank you for the feedback. Inform me in case you will find something more.

Piotr Szymczak
@Drutol

But wouldn't it be better to be even more abstract and go for a solution that supports EventSource as well as myriad of other providers? Regardless of what we do EventSource won't work on Mono while with abstract logging interface it would be left to end user's discretion.

EventSource is designed to interface with the underlying operating system's logging infrastructure, e.g. Event Tracing for Windows (ETW.aspx)) or LTTng on Linux.

EventSource is an implementation which is enforced upon end user and while it allows to attach some additional sinks it's still an implementation... OS dependent at that.

Mariusz
@mpostol

If you are sure it doesn't work on mono just report it will see the answer. Now we are talking about two things:

  1. Documentation - yest it has errors.
  2. Platform dependency - i have evidence that it works on many platforms not ETW aware - it proves that the documentation is wrong, but the error has been just reported.

I am pretty sure that EventSource is a generic solution and can be implemented on any platform somehow that make sense.
Anyway, thank you for feedback.

Piotr Szymczak
@Drutol
image.png
I'm scavenging info from the Internet.
I'm pretty lost with this issue too. :(
Mariusz
@mpostol
All, on branch 400 i have just commuted release candidate for 4.0. I am going to PR it to master and start working on final release of 4.0.
Mariusz
@mpostol
@AdamBorowiecki The release has breaking changes especially related to transport but it is preferred version to be used for external transport providers. It will make transport related components more robust against the future library changes.
@Drutol for your work it seems some definition has been moved to separate .dll
There are still some UT that fail so I will work to fix them soon. In the mean time please report me if there are some breaking features that must be fixed.
Piotr Szymczak
@Drutol
@mpostol 4.0 alpha is working correctly in my app :)
Mariusz
@mpostol
@Drutol Great, so I will go ahead. Many thanks.
Mariusz
@mpostol
@Drutol I have just released version 4.0.1. https://github.com/mpostol/OPC-UA-OOI/releases
Piotr Szymczak
@Drutol
:tada:
Mariusz
@mpostol
Now work is focused on the Export model. Scope: add UAModelDesingn generator implementing IModelFactory, Unit Tests, add command line application (tool).
The work will be conducted on the SemanticData branch and merged to master after accomplishing this milestone. The release is planned.
Mariusz
@mpostol
:tada: Object-Oriented Internet SemanticData ModelDesign Export 5.0.2-Alpha is available
The main goal of the Release 5 is to add export of the OPC UA Address Space to ModelDesign XML file.
This update comprises the following changes:
  • Updated the UA Address Space instantiation against OPC UA Specification 1.04
  • Updated UANodeSet schema up to 1.0.4
  • Published OPC UA Address Space Prototyping Tool (asp.exe) allows export to ModelDesign XML format.
    To get more visit the online documentation
    OPC UA Address Space Prototyping Tool (asp.exe)
Mariusz
@mpostol
New set of documents is ready for review on the SemanticData branch. Good starting point is Address Space Model Life-cycle.
Mariusz
@mpostol
The new content of the following document is ready for community interview:
OPC UA PubSub Main Technology Features
Joesan
@joesan
Hallo guys.... is this OPC-UA-00I compatible with Part 14 of the OPC UA Spec which is the Pub/Sub architecture?
Mariusz
@mpostol

@joesan sorry for the delay, but I haven't got notification from this thread.

The answer is yes with the Ver 1.1. of the protocol.
The binaries are available here:
Networking -Internet of Things (IoT) Communication

There is a note:
This release contains modifications required to start interoperability testing against PubSub protocol version 1.10.

Standardization of the new version of the protocol is still in progress
AMENDMENT 6 - UADP Header Layouts (DOC/ZIP)

Now I am working on the protocol description using ABNF
OPC-UA-OOI/Networking/SemanticData/MessageHandling/
available on the Network branch.

Mariusz
@mpostol
I have added the Augmented BNF definition of the NetworkMessage. NetworkMessage is originally defined in OPC UA Part 14 Release 1.04 February 06, 2018
Augmented BNF is defined in the document Augmented BNF for Syntax Specifications: ABNF RFC 5234
The document is available here
NetworkMessage.abnf
Mariusz
@mpostol
In case you have missed. Let me know how it works for you.
OPC UA PubSub over TSN Demystified
Mariusz
@mpostol
Check out my latest article:
UAModelDesignExport Library
Mariusz
@mpostol

Check out new Release 5.1

This update comprises the following changes:

  • semantic-Data (Details in section SemanticData)
    • updated against OPC UA Specification 1.04; new API
    • added export to UAModelDesign
  • documentation improved
  • new code help documentation available
Mariusz
@mpostol

CAS OPC UA Address Space Model Designer is moving to open-source

Let me inform you that CAS OPC UA Address Space Model Designer has been just published on GitHub as the open-source:

OPC UA Address Space Model Designer

For now, it is a stand-alone project, but any ideas related to harmonization with your needs are welcome. Further development and priorities will be derived from community feedback. The old installation package is still available on the commsvr.com web-page:

http://www.commsvr.com/COInstal/UAModelDesignerPro/setup.exe

I am also in the process of moving the CommServer software family to open source. The master plan is available here:

CommServer - management of migration to open source

Any questions, suggestions, and proposals are welcome.

Mariusz
@mpostol

OOI and ASMD harmonization

Visit the harmonization to learn more
I have commenced a preparation stage. All feature requests are gathered as the comments of mpostol/OPC-UA-OOI#400.
Mariusz
@mpostol
Let me inform that there is a new citizen added to the Object-Oriented Internet World. Check it out to learn how to control the software functionality using a license file.
Mariusz
@mpostol

I am excited to share that my article titled Object-Oriented Internet Reactive Interoperability is to be published in Lecture Notes in Computer Science series, on behalf of Springer.
It is not about OPC UA but it refers to this standard pointing out further development directions. From these proposals, a question may be derived

Do we need the OPC UA Rel. 2.0?

Contact me by message to get a preprint version of the article. I am going to prepare an article to aggregate your comments and summarize what is missing.
Consider addressing this topic during OPC Day 2020 - International - is coming soon.

Read more on researchgate.net

Mariusz
@mpostol

I have released the new version 4.3 of the Address Space Model Designer. In this release, many bugfixes have been applied. Check it out and let me know how it works for you. This version is available here:

https://github.com/mpostol/ASMD/releases/tag/4.3.0

Now on my road map is version 5.0. The scope is defined by the milestone 5.0