I was reviewing Etsi's standards on M2M, IoT and came across this document.
I saw MainFlux mentioned on pages 37 and 38 and I was curious if MainFlux's implementation is OneM2M compliant?
Mainflux maintainer here.
It is not OneM2M compliant.
Related
.Net Core (as of now) lacks the System.Net.Mail namespace and the preview version of this namespace which is available through nugget lacks SmtpClient which is the most important type of it. However, if one does not like to use class libraries for some reasons (such as to be an independent hero), is there any way to send an email using the available tools in .Net Core (HttpWebRequest, HttpClient, Sockets, etc.)? If so how could this be done (example and not theory).
You absolutely could write your own library to send emails. The question is "Should you?" The amount of time required would not be a worthwhile endeavor unless you fully intended to make the library available to a broad audience.
The original SMTP Specification (RFC 821) (https://www.rfc-editor.org/rfc/rfc821) was about 68 pages. Implementing this specification was "doable" but required significant effort. The newer SMTP Specification (RFC2821) (https://www.rfc-editor.org/rfc/rfc2821) is 79 pages.
Beyond the implementation of the functionality specified in RFC 2821, you also need to be familiar with a number of other RFCs and documents. (A brief look through the references listed from pages 68 to 70 will certainly give you a bit of pause.)
The best options for anyone sending Mail with .NET Core would be to either use a service such as SendGrid (http://sendgrid.com/) or a free and open source library like MailKit (https://github.com/jstedfast/MailKit). I believe that most .NET Core deployed sites are using one of these two methods for sending emails.
Steve Gordon did a really nice blog post (https://www.stevejgordon.co.uk/how-to-send-emails-in-asp-net-core-1-0) on using the MailKit library with ASP.NET Core.
Even if you wanted to build your own SMTP library (and I am definitely not advocating that), the best approach might be to fork something like MailKit (https://github.com/jstedfast/MailKit) via GitHub and then modify it. That would at least allow you to play with and iteratively modify a working implementation.
Most of your work would be done using components from the System.Net.Sockets namespace. Here is the reference for .NET Framework 4.7 version (https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets?view=netframework-4.7). It should be fairly similar to the .NET Core implementation although I have not tested it.
Sometimes the best advice is "Just because you can doesn't mean you should." Please don't be an "independent hero." Go with what works.
We have detected FHIR Query resource is missing in FHIR Continuous Integration page.
Nevertheless,it´s present in Java implementation in zip library for that branch.
We are using this resource in certain FHIR messaging services which are already implemented: Message Bundles with at least MessageHeader and Query resources.
Will Query be present in DSTU2 or the missing is simply an integration error for documentation?
Thanks in advance for clarification.
Regards
Query has been supplanted by the notion of OperationDefinition, though how this is done in the messaging space isn't fully documented yet. The reference implementations aren't yet fully aligned with the draft specification. Both of these deficiencies will be corrected before the DSTU ballot opens in April.
Section 2.1.1.5 here (http://hl7.org/implement/standards/FHIR-Develop/search.html) will describe this usecase for you, however this section is not finished yet. It will be based on the way operations are invoked asynchronously (see 2.2.0.5 here http://hl7.org/implement/standards/FHIR-Develop/operations.html). This section is also sketchy. I will take this up with Grahame and Lloyd to flesh it out.
hello again, WSO2 community.
My last question about your architecture for my research is not a technical question, but a future-oriented one instead.
I was thinking about the OSGi approach the Suite has, that is one of the most interesting abstract things about SOA in general and WSO2 in particular I have found. An OSGi is sure a puzzling puzzle.
Thinking about pieces connected together reminded me about Service Component Architecture: a mean to see all the pieces as a whole easier.
Well, my question, son of my thoughts, is: "Why not to enable SCA for WSO2, when all the pieces have Carbon as a common denominator?" Carbon seems to be a nice candidate to be SCA.
The architecture could have only one instance of Carbon underneath, and WSO2 components above. The user should be able to interact with Carbon through only one interface and see all the pieces and their installed feature.
Is it possible? If it's not, why?
I hope I've been of some use through all the way here, and I thank you for having accompanied me to the end of my journey!
I hope there will occasions to collaborate or simply sharing ideas again!
It is conceptually similar to what it does with OSGi and Endpoint References in Carbon App model. Possibly can look at SCA Assembly as an alternative wiring model.
I'm studying business layer and need a complete reference which covers issues about "how to manage dependency between business layer and other layers", "how many ways are there to send data between layers" and most important for me "how to group business logic and make business component and talk about possible ways....".
do you know any reference?
EDIT:
I would be delighted if you introduce some e-book for it.
Thank you
the best (in my opinion) approaches to decoupling layers it to use a message passing metaphor. This way communication between the layers is done with messages that are types that contain information only pertinent to the communication. These light weight types are then interpreted by each layer as they see fit.
In essence don't pass things that are not needed. If both layers need a piece of information then there is a high likely hood that some other entity should be brokering access to that information (for example persisted data in db).
I recently stumbled onto this one and found it to be a great read (free ebook in PDF, or read it in MSDN), got the printed version on Amazon shortly after.
Microsoft Patterns & Practices Application Architecture Guide 2.0 -
http://apparchguide.codeplex.com/
EDIT: Here's the section on Business Layers in the MSDN version: http://msdn.microsoft.com/en-us/library/ee658103%28v=PandP.10%29.aspx
I think you should consider reading these books.
(source: infibeam.com)
How about something like
Three-Layered Services Application
(source: microsoft.com)
and
Layered Application
I started using IRC at a young age, and I have always been fascinated with it. As a language exercise, I was thinking about programming a simple IRC client in Ruby with Shoes as a graphical front-end. My question to you, kind-sirs, what do I need to become familiar with to start on this great adventure (besides shoes and Ruby of course)? I imagine there is some-sort of specification on IRC Protocol. Any pointers?
An earlier post mentioned RFC1459. While it is a very good introduction to IRC, it has actually been superseded by RFCs 2810-2813. Here is a more complete list of documentation you need to program anything IRC-related:
RFC1459 (original RFC; superseded, but still useful)
RFC2810 (IRC architecture)
RFC2811 (IRC channel management)
RFC2812 (IRC client protocol)
RFC2813 (IRC server protocol)
CTCP specification
DCC specification
Updated CTCP specification (not all clients support this)
ISupport (response code 005) draft (almost all servers support this nowadays)
Client capabilities (CAP command) draft (supported by some servers/clients)
IRCv3 standards and proposals (the future features of IRC, some of which are already widely supported)
The IRC Specification is laid out in RFC 1459
http://www.irchelp.org/irchelp/rfc/rfc.html
I found this gem on Wikipedia. Sounds intimidating.
It's actually not.
Telnet onto an IRC Server and witness the simplicity of the protocol first hand. The hardest part is the handshake, after that its very simple.
I once implemented a client and a server with 2 more guys (as part of a course).
I can tell you that the RFC you were already linked to is great.
I'd also try simply sniffing a connection with an existing client to see for yourself how stuff work.
Not exactly an answer to your question, but it may be helpful. If you are using Ruby, I have found the Autumn Leaves project to be a great way to build an IRC bot using Ruby:
http://github.com/RISCfuture/autumn/tree/master
It is pretty much the Jibble of the Ruby world.