3 ms·

> The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow sh

> The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. And when we live in your Star Trek-style technoutopia, then we won't have to worry about business concerns in specs. Specs have had business concerns in them since... ever.

chime 14y ago
I agree with you that business needs give rise to specs. That's pretty much how most of the specs are born. MS wanted to make Outlook Web Access behave more like the desktop version and came up with XMLHttpRequest - which went into the spec and made the web of today suck significantly less. That wasn't my point. I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.
- UIZealot 14y ago
  > XMLHttpRequest... made the web of today suck significantly less. I would argue the exact opposite.
  - mayanksinghal 14y ago
    I am curious. What are your arguments?
    - nacs 14y ago
      Likely referring to web-apps that require Javascript support and have no fail over code. This is more a problem with the developer of said site and not an issue with XMLhttprequest as you can build apps that are progressively enhanced for it and don't fail completely when JS/XMLHTTP is disabled.
  - chime 14y ago
    If you've upvoted or downvoted anyone here on HN, you have benefited from XMLHttpRequest.
    - genwin 14y ago
      HN doesn't use XMLHttpRequest. View source to see that.
redbad 14y ago
Specs have had business concerns in them since... ever. Good specs haven't.
- FourthProtocol 14y ago
  Good specs do. You might write a spec that describes the functional requirements of a claims processing system, because your current system is 20 years old and can't cheaply be modified to comply with legislative changes. An obvious "business concern" is that any replacement system will accommodate future legislative changes. This has nothing to do with the functional (user) requirements (form design and submission process), and yet might dramatically change how you design and write such a system. DRM, or rather the encryption scheme that makes it DRM, is much the same in that a design that supports it could similarly support related but more benign capabilities, such as compression or translation. That too will influence an implementation, and makes such a non-functional requirement as important as a functional requirement.

chime 14y ago

I agree with you that business needs give rise to specs. That's pretty much how most of the specs are born. MS wanted to make Outlook Web Access behave more like the desktop version and came up with XMLHttpRequest - which went into the spec and made the web of today suck significantly less. That wasn't my point. I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.

UIZealot 14y ago
> XMLHttpRequest... made the web of today suck significantly less. I would argue the exact opposite.
- mayanksinghal 14y ago
  I am curious. What are your arguments?
  - nacs 14y ago
    Likely referring to web-apps that require Javascript support and have no fail over code. This is more a problem with the developer of said site and not an issue with XMLhttprequest as you can build apps that are progressively enhanced for it and don't fail completely when JS/XMLHTTP is disabled.
- chime 14y ago
  If you've upvoted or downvoted anyone here on HN, you have benefited from XMLHttpRequest.
  - genwin 14y ago
    HN doesn't use XMLHttpRequest. View source to see that.

redbad 14y ago

Specs have had business concerns in them since... ever. Good specs haven't.

FourthProtocol 14y ago
Good specs do. You might write a spec that describes the functional requirements of a claims processing system, because your current system is 20 years old and can't cheaply be modified to comply with legislative changes. An obvious "business concern" is that any replacement system will accommodate future legislative changes. This has nothing to do with the functional (user) requirements (form design and submission process), and yet might dramatically change how you design and write such a system. DRM, or rather the encryption scheme that makes it DRM, is much the same in that a design that supports it could similarly support related but more benign capabilities, such as compression or translation. That too will influence an implementation, and makes such a non-functional requirement as important as a functional requirement.