hello. i don't mean to sound critical and am not critical. i think this is a terrific article. but please help me understand. i question the value of what is being done here. so we're drawing components and we're taking a snapshot and then we're including the image on a web page.
my impression is that text-based buttons should be preferred over image buttons. the additional images increase latency and if the image doesn't come up then you won't know what the button is saying. or the image comes up the page load takes longer. you have extra network calls to the server to get each image. so the user is made to wait until the entire page loads, with all the images, to be able to tell whether the button says 'ok' or 'cancel'.
when i think of swing as the client, i think of replacing the web browser and the html with a custom, rich, gui; not of somehow playing in the web page sandbox alongside html.
i strongly believe that a swing client is an improvement over an html client, to the extent that a swing client can be developed in the same amount of effort (or less) than web.
in my mind, the issue is coming up with a good mechanism to deal with the distance, the latency of the network communication: the transport layer. data models that exist on the server must be bound to the client in a manner that does not significantly increase the chattiness of the conversation (and thus increasing the load on the server possibly considerably). the client inevitably provides means for the end user to make changes to that model, changes that must be communicated back to the server. we need a mechanism to make this all scale to dozens of concurrent users, possibly more.
it'd be nice also to consider not being restricted to the http protocol model of opening and closing connections. preferring maintaining a connection with the server open for the duration of the session, thus eliminating jumping through hoops with cookies. on the other hand, do such servers exist off the shelf? i want to see that infrastructure develop, something that one day will become as standard or ubiquitous as http is today. |
java.net RSS Feeds
