I thought that this was an interesting discussion that if was to be continued in my comments, many of you might miss it (I know how difficult it is to follow comments on blogs).
Mark believes that I didn’t answer his question. Hmmm… Perhaps I didn’t understand the question then.
I think that Internet mail is an application and I am sure that Mark agrees. And of course, lots of clever people designed the architecture on which that application is based. And I am sure that these architects had a set of architectural principles in mind during the design phase. Such architectural principles may match, be a superset, or a subset of the MEST ones. Exactly the same could be said for any asynchronous messaging-based application out there. That doesn’t mean that MEST is only about asynchronous messaging however. MEST is an architectural style in the same way REST is one and we can find many applications out there (not just the Web) that follow the REST approach. MEST is a set of principles (one-way messaging, services, constrains on the messages, no interfaces, implicit uniform message processing semantics at the service end point, focus on interaction contracts and other metadata, etc.) most of which, if not all, have probably already been applied in existing applications.
If the suggestion is that the principles on which the Internet mail application is based are those that MEST talks about, then I don’t have a problem with that. We never tried to suggest that MEST represents something new in distributed computing. MEST just gives a name to the set of principles we think are important when building service-oriented applications. Let’s not forget that the Web also pre-existed REST.
As for Stefan‘s question about the distinction between transport, transfer, and application protocols that I mentioned in my previous post… I personally see a transport protocol as the mechanism put in place for a message to be moved from one point to the next (just the bits). A transfer protocol is the set of rules (e.g. structure, extensibility, and composability) and semantics for processing that message after it leaves the originating endpoint and before it reaches the receiving one (please note that endpoints are logical here and represent the boundary between a service’s logic and the outside world). An application protocol represents the collection of messages (an interaction, a process) and associated semantics which are put in place to implement some specific functionality.
The way a particular protocol is treated is relative. For example, SOAP is a transfer protocol which treats both HTTP and TCP/IP as transport ones when building Web Services applications. However, HTTP is an application and a transfer protocol at the same time when building Web applications, with TCP/IP being a transport protocol. Most probably not everyone agrees with this distinction so I’d be very interested in other people’s views. Start blogging everyone (please wait until I catch up with all my many unread blog posts first though 🙂
I am embarking on a side project that involves memory and multimodal understanding for an…
I was in Toronto, Canada. I'm on the flight back home now. The trip was…
The BBC article "How we fell out of love with voice assistants" by Katherine Latham…
Like so many others out there, I played a bit with ChatGPT. I noticed examples…