Hey everyone. This may be a bit out there. I'm a developer and certified instructor in Qigong - an ancient mind body practice. Some months ago I decided to apply AI to create modules that support the exploration of these mind body practices. Would love some feedback.
Reading through the comments here I'm realizing that my single biggest error may have been the use of the word "Universal" :-D When you consider the spec as a "basis for agreement" between distributed application authors and not a unified theory of messaging - then the spec becomes a lot clearer.
The spec describes a message format and isn't intended to be a formal Internet RFC. As such, the thought was to leave definitions up to users rather than dictate things like priority ranges.
Thanks for this. The need for canonical JSON is perhaps the best reason for dropping the signature field from future versions of the spec. However, because only the `to` `from` and `body` fields are required there's no need avoid the format - just don't use the signature field unless the body field contains a single field with serialized data. Certainly, that use would need to be clearly documented.
Again your point is valid and will likely result in the depreciation of the signature field.
The point about inconsistent formatting is that by aligning a team(s) on how a message is formatted groups can avoid the introduction of multiple message formats between distributed services.
It's true the body field does introduce inconsistency and that's left for the application developers to resolve. The envelope fields are intended to be used in queuing and routing situations.
I disagree with "The destination doesn't need to be in the message". What about the use case where a message is forwarded or moves through proxy services?
+1 for metadata being larger than the payload :-D - Can't debate that. The only required fields are 'to', 'from' and 'body' and the short form of UMF can be used. Still, we've encountered situations where that metadata is still larger than the payload. But that doesn't completely invalidate the presence of the envelope in a distributed application.
Thanks, I really appreciate the time you took to offer feedback!
In an earlier version of the docs I actually had the spec in the readme but felt the sheer size was enough to send folks running. Using the readme to describe the spec (which I realize needs work!) allowed for a clean separation.
Hahaha. My dude, it's a damn good thing I'm not applying for your startup! And a great thing that my current and past employers didn't think I should resign. So you know what? I'm going to keep up this charade for a bit longer. Besides, the pay is great! :-D
The conical issue with regards fields and signatures is definitely and without question a valid point and should probably be removed from the spec.
You raise good points. I'll definitely reconsider your feedback in future iterations!
Your point about a logging field is interesting, but the MID field could be used in an out of band error acknowledgment.
Protobuf is great - but what if you don't need or want it?
Ah Linus - enough said. The UMF spec wasn't intended to be a standards paper. You might be able to tell it isn't formatted as such. Based on the comments in this post - it has at the very least helped spark interesting feedback and debate.
Wow - I really ruffled some feathers with this post :-D As I scanned the feedback, I found myself agreeing with some, but not all, of the comments.
I actually found some of the direct attacks amusing and got a good laugh. That said, I'd like to thank everyone who took the time to comment. One of the goals of any specification should be to iterate the spec based on the valuable feedback of others. I'll definitely take this opportunity to do that.
I don't think that's delusional - the same approach has certainly worked for me - when it's been necessary. Sometimes you just have to go into crunch mode and make shit happen.
Given that there are a great deal of service APIs in the wild this is going to lower the barrier of entry for many less experienced developers looking to prototype their ideas.
Depends on what you'll be doing with the laptop. If you're a graphic designer or gamer color matters. If you're in spreadsheets or surfing the web it might matter less. If you're planning on watching lots of videos - color matters.
If you're in an environment where you can control the lighting around you then glossy works just fine - otherwise matte might be necessary.
From your post it seems you're not quite ready to leave. So trying to share your insights and raise awareness may be worth a shot. That is, if you can comfortably speak with upper management without being singled out.
If the company is profitable and the users are pleased with the product then from an upper management perspective there may not be anything wrong. Until the bottom line is impacted there may not be leverage for change. The key is to alert management to the state of the product and the course it's on.
Parallel development may be an option as the next release of the product would address the underlying issues. This is costly and upper management would have to understand why that's necessary.
When starting off you can combine the two. Many startups do this. Find a person who has started his/her career in sales and eventually moved into Marketing.
Agreed that if your goal is not mastery you can actually learn the basics of a language and become semi-productive in a month. Anything more requires exceptional skill, or more likely much more time.
Checkout the book "Outliers" by Malcolm Gladwell. Gladwell asserts (not originally) that it takes 10,000 hours to master a subject.