I was offered 100 Mb/s by Bredbandsbolaget, but they wanted to cap it at 300 GB/month. I wouldn't use that much myself, but the thought of a cap made me not take the deal and stay with the 10 Mb/s deal. Full duplex mind you.
However, no way how you slice and dice this, the people in the UK really do live in the 1800's bandwidth-wise.
Well, the method name and parameters are actually a character stream in the HTTP post, IIRC. You could still, I think, do what you are saying with a filter, but you are going to have to unmarshall the call from the input stream instead of just callng getParameter. However once done, you could do all kinds of weird and wonderful things with it if you were so inclined. The drawback is that it is not transparent at all to to the on-wire data representation
True, it might be somewhat difficult to do it. However, I'd say that that is the best option today. And once you've dont it, you can reuse that for all your JSON stuff.
However, I do agree that it certainly isn't a bad idea to have it as part of the JSON framework, assuming they support some type of pluggable authentication modules. Because of the suckyness of the standard servlet authentication methods most people have designed their own and they need a way to plug into that.
Well, again a servlet filter is certainly feasible, but not easily maintainable for the reasons cited in my prior post. WRT to the handler methods, if you are talking about the target objects, they are POJOs so you don't want to put a lot of stuff in them that knows about sessions and what-not, otherwise you lose all the POJO flexibility and testability. Which is why something AOPish works very nicely here.
Like, why? You most certainly want to create some kind of front-end objects which the JacaScript page can use. Note that I'm not talking about the value objects here. I'm talking about the service objects which provides the information to the web pages.
Just because the framework is flexible enough that it can support plain java objects doesn't mean it's a good idea to do so.
So far as the suckiness of AOP, I think there is nothing wrong with the paradigm, just the current tools used for AOP.
I find the concept flawed, mostly with regards to readability and debugability. This is, however, not the right forum to discuss that.
No, not corny at all. Remember that this was 1984. This was back when the C64 was considered state of the art. The PC programs were text only. Most people in the audience had never seen anything like that before.
And exposing application logic with no more security thant "normal web access" is a good thing?
I never said exposing application logic is a good thing. No self-concious developer are going to take their existing application classes and expose them through JSON. You write specific front-end classes that the JavaScript can use. The security can be placed wither in the servlet filter or in the front-end class.
And which, by default is what happens if you just remote your objects using JSON. What I'm saying is that this could be improved upon.
Doing that is so stupid I never even thought about it.:-)
Now, the thing to remember JSON helpfully creates a session for you if you don't have on. So relying on the session to be created by your login page won't work, unless you have every object referenced by the JSON servlet check the session to make sure it is legit -- which is ugly.
Yes, a servlet session is created on every access. However, I said "which binds a principal to a session". The key word here is "principal". Once this is done, you can use the standard servlet security mechanisms to allow/deny access to the JSON handler servlet as a whole.
For more fine-grained control you'll have to use code in the handler methods or use the servlet filter.
Your ServletFiler idea is essentially the same as my suggesting that we could apply an AOP interceptor on method requests.
I'm no fan of AOP, the less the better. Why suggest AOP here when servlet filters are specifically designed for that purpose?
Suppose every class has a properties file listing who is allowed to access each of its methods.
[ most of the examples snipped ]
Not a bad idea, and I'm sure something like this will be introduced in JSON. However, assuming JSON puts the method name in a request parameter (or in some other equally easy to reach place) you could implement all of this in a servlet filter that wraps the JSON handler servlet. Thinking about it, I think I'd be able to cover all of your suggestions in a single filter. It wouldn't even be particularily complicated.
It certainly looks interesting too. It seems to do pretty much the same thing as JSON. Could you explain in what respect japano is better than JSON? (note that my experience with neither of these exceed 5 minutes).
Nothing prevents you from using it today. The browsers have the required support. All you do is write the containers, add the code to your JSP, add the JSON servlet to you app server and just use it.
I think I'll use this. I've dreaded to do it manually and this is just what I need.
You obviously understand how the system works, but you failed to understand exactly what it does.
JSON is not less secure than normal web access. Say you have a servlet mapped as such:
http://myhost/DeleteFile?name=/etc/passwd
which allows you to delete the/etc directory. Unless you enable some kind of security mechanisms, anyone can delete anything in the system.
The same is true for JSON. Sure you can expose a deleteFile() method, but it would be just as stupid as the above mentioned URL. You always have to add some security and you do that the same way regardless of wether a request comes in to a servlet which you write or via JSON.
The typical way to handle authentication is through the application servers login stuff which binds a principal to a session, or you do it by hand by using a ServletFiliter on top of the pages (and the JSON servlet).
Not quite correct. What you said was true for JDK1.1 and earlier. Since 1.2 (released back in 1997 or so) you can have it display a warning saying "this applet wishes to connect to the following server: 123.123.123.123" [Allow|Deny]. Thanks to the sandboxing, security in Java is not an all or nothing affair. The applet developer can select certain permissions it requires.
There are some porn movies that use it. Other than that I've only seen one use of it which is not porn-related and that was in the extra features for some movie (can't remember which). It allowed you to see the filming of a scene from several cameras on the set. Pretty cool actually.
When Sony and the other partners came up with DVD, the first high-end duplication machine (and licensing deal) in the United States was with Vivid Video. Thus ensuring the success of the format.
It certainly does seem like Sony learns from its mistakes.
Yes, and since I wrote the previous post other people have commented that Sony actually prevented porn companies from licensing the technology. A recipie for failure if you ask me.
I've been saying this for a long time. The porn industry is driving technology.
Why did VHS win and Betamax fail? Some people (including me) argue that the biggest reason is that all th eporn was available on VHS. Wasn't there a statement against porn from the betamax people?
Which industry was the only industry for a long time acually delivering profits selling stuff on the web during a time when all other industries promised a lot but only delivered losses?
And remember the multiple-angle button on the DVD players? Who really thinks that this button was designed for the sports industry?
I think the article hits the nail right on the head. The porn industry will decide which format will be used.
The quoted post refers to the heavy bending of optical cables used in one of the pictures. Optical cables should not be bent more than a certain amount to prevent the actual fibre from breaking.
In essensce, no there is no need to buy "air cables" for over 1000 per metre. Computer engineers are usually not as guillable as "audiophiles":-)
At the turn of the century, people were worried that New York City was growing at a rate that would result in the streets being literally knee-deep in horseshit by the 50s.
I know I'm nit-picking, but didn't you mean "at the turn of the last century"?
Slashdot Mirror
However, no way how you slice and dice this, the people in the UK really do live in the 1800's bandwidth-wise.
I will take a look at it to seeif it suits out needs better. Thanks for the information, it's quite unusual here. :-)
However, I do agree that it certainly isn't a bad idea to have it as part of the JSON framework, assuming they support some type of pluggable authentication modules. Because of the suckyness of the standard servlet authentication methods most people have designed their own and they need a way to plug into that.
Like, why? You most certainly want to create some kind of front-end objects which the JacaScript page can use. Note that I'm not talking about the value objects here. I'm talking about the service objects which provides the information to the web pages.Just because the framework is flexible enough that it can support plain java objects doesn't mean it's a good idea to do so.
I find the concept flawed, mostly with regards to readability and debugability. This is, however, not the right forum to discuss that.No, not corny at all. Remember that this was 1984. This was back when the C64 was considered state of the art. The PC programs were text only. Most people in the audience had never seen anything like that before.
For more fine-grained control you'll have to use code in the handler methods or use the servlet filter.
I'm no fan of AOP, the less the better. Why suggest AOP here when servlet filters are specifically designed for that purpose? Not a bad idea, and I'm sure something like this will be introduced in JSON. However, assuming JSON puts the method name in a request parameter (or in some other equally easy to reach place) you could implement all of this in a servlet filter that wraps the JSON handler servlet. Thinking about it, I think I'd be able to cover all of your suggestions in a single filter. It wouldn't even be particularily complicated.It certainly looks interesting too. It seems to do pretty much the same thing as JSON. Could you explain in what respect japano is better than JSON? (note that my experience with neither of these exceed 5 minutes).
I think I'll use this. I've dreaded to do it manually and this is just what I need.
JSON is not less secure than normal web access. Say you have a servlet mapped as such:
which allows you to delete theThe same is true for JSON. Sure you can expose a deleteFile() method, but it would be just as stupid as the above mentioned URL. You always have to add some security and you do that the same way regardless of wether a request comes in to a servlet which you write or via JSON.
The typical way to handle authentication is through the application servers login stuff which binds a principal to a session, or you do it by hand by using a ServletFiliter on top of the pages (and the JSON servlet).
That can't be it. The 5 Discovery channels are not free in the UK.
- A complete sandbox (not flexible enough)
- "Trust me, I'm nice" the ActiveX way (pretty much wide open)
- Detailed security (too complicated to understand the question that is asked)
Well then, according to you, what solution which doesn't suck do you suggest?Not quite correct. What you said was true for JDK1.1 and earlier. Since 1.2 (released back in 1997 or so) you can have it display a warning saying "this applet wishes to connect to the following server: 123.123.123.123" [Allow|Deny]. Thanks to the sandboxing, security in Java is not an all or nothing affair. The applet developer can select certain permissions it requires.
There are some porn movies that use it. Other than that I've only seen one use of it which is not porn-related and that was in the extra features for some movie (can't remember which). It allowed you to see the filming of a scene from several cameras on the set. Pretty cool actually.
Yes, and since I wrote the previous post other people have commented that Sony actually prevented porn companies from licensing the technology. A recipie for failure if you ask me.
Why did VHS win and Betamax fail? Some people (including me) argue that the biggest reason is that all th eporn was available on VHS. Wasn't there a statement against porn from the betamax people?
Which industry was the only industry for a long time acually delivering profits selling stuff on the web during a time when all other industries promised a lot but only delivered losses?
And remember the multiple-angle button on the DVD players? Who really thinks that this button was designed for the sports industry?
I think the article hits the nail right on the head. The porn industry will decide which format will be used.
No. That would be "the turn of the centennial". I'm not even a native english speaker but apparently I grasp the language better than you do.
In essensce, no there is no need to buy "air cables" for over 1000 per metre. Computer engineers are usually not as guillable as "audiophiles" :-)
Not really. The cost of the material doesn't go up just because it takes lonker to make.
physical property = time * effort + material
This makes the material bit kinda irrelevant to the entire equation, and thefefore can be ignored for the purposes of the grandfather post.
The customers will still most likely be getting a media player included. The PC vendors are able to install it on their preinstalled machines.
No, it's not the same thing. Yes it would have been the same thing if Apple had been a monopoly.
As has been said many times before, being a monopoly places more restrictions on what you can do compared to when you are not a monopoly.
That's why you should go to java.sun.com, not www.java.com
Singapore does. They have .com.sg, gov.sg, etc...
Unless you are the owner, in which case I wish you good luck with your company.