Print

Print


1. As a developer, I like the concept, for obviously the same reasons you do. Except one reason: it means the server would be required to have a JavaScript interpreter (or at least have access to such an interpreter somehow, architectures can get complicated). This is easy if the server itself is written in JavaScript, otherwise not so much.

2. As an engineer, I hate the concept, because it introduces a security problem into the specification - malicious code could be injected into the server. So far, the WebLVC PDG hasn't discussed security much at all, assuming this is a closed network or that security problems are solved by some other means out-of-scope. I realize the filter function would run in a sandbox and might probably be safe - but since I'm no security expert I hesitate.

While neither of those are deal-breakers, I suggest we at least hold off until post 1.0 release. Also, I'd require more convincing to vote in favour.

However, there's nothing in the spec that prevents implementing extensions to the spec. In fact, it's expected in the case of new messages and attributes; your proposal could be viewed as adding a new attribute. Using that new attribute would limit the portability of those clients, of course. 

In fact - perhaps your experiments would make a good paper for SIW? 
Fame, fortune, television advertising and endorsement contacts await you!
########################################################################

To unsubscribe from the SAC-PDG-WEBLVC list, click the following link:
https://discussions.sisostds.org/index.htm?SUBED1=SAC-PDG-WEBLVC&A=1