Solution design
- From: "Sorin Dolha" <sdolha@xxxxxxxxxxxxxxxx>
- Date: Tue, 30 Aug 2005 11:32:11 -0700
Hello,
We intend to create an ASP.NET-based Web application (hosted on Internet
Information Services, or IIS) and one feature of the application needs to
allow the end user to upload photos to the server.
However, our customer requests that both of these two objectives to be
supported by the design of the solution:
1. The photos should be encoded as JPG, and resized (if larger than a
maximum adminisible width/height) on the client side, before the actual
upload.
2. The upload (and the whole application) should work on multiple browsers
supported on multiple platforms, running with the default user security
settings (explicit request includes, but are not limited to: Internet
Explorer on Windows and Macintosh, Mozilla Firefox on Windows and other OSes).
The first request would trigger for creating: a .NET-based user control
hosted in Internet Explorer, or a ActiveX component hosted also on the web
site, or a Java applet. Personally, if it weren't for the second request, I'd
choose the first choice (.NET-based user control as it is the most flexible
and uses the advantages of the .NET technologies even on client side).
However, the second request would trigger for Java instead, as .NET (or
COM/ActiveX technologies are not running on the requested platforms/browsers).
For testing purposes, we tried to create a Java applet that was trying to
allow a user to select an image using a FileDialog window, and then trying to
open the image, convert it as required and then upload the resulting bytes
back to the server. This seemed to be OK, but unlike .NET, Java applets do
not allow implicitly to open a file stream on the client host even if it was
selected by a user n a FileDialog window (I know .NET default security
permissions would allow that, because I already used it in another
application). In this case, we tried to sign the applet using the steps
presented by Sun on their Web site due to no avail: an exception
(AccessControlException, with access denying on socket creation for getting
the image file from the local client host) was generated even if the jar was
signed (with a test certificate, tough - but even in this case, the browser
should have asked the end user whether or not she trusts the applet and allow
it to run if accepted - at least that's what Sun documentation sais...)
Now, because we feel that a java applet is not an as good idea as we first
thought due to the default security permissions higher than actually
necessary (i.e. reading a file should be allowed if the file was selected by
the user in a FileDialog...), we are back to the design table, and looking
for some advice from anyone else, if available: what do you think? What is
the best approach we could do to meet both of the customer requirements and
still create a nice solution (such as a .NET-only one)? :)
PS: Maybe someone knows where to find a JPEG encoder written entirely in
JScript running on the client with a HTML FileUpload control as the source
for the file, before actually uploading it, or is it something too difficult
to write entirely in JScript?
--
Sorin Dolha, DlhSoft
MCAD, MCSD .NET
.
- Follow-Ups:
- RE: Solution design
- From: Steven Cheng[MSFT]
- RE: Solution design
- Prev by Date: Why does try/catch require {}
- Next by Date: Re: Why does try/catch require {}
- Previous by thread: Why does try/catch require {}
- Next by thread: RE: Solution design
- Index(es):
Relevant Pages
|
