I am writing a data collection application. It needs to run on as many
tablets and laptops as possible, so I'm writing it in HTML and
JavaScript. Although I cannot ask end users to buy a particular device,
I can ask them to install an up to date browser.
The ultimate destination of the data is a spreadsheet on a workstation
controlled by the person doing the data entry, or one of their associates.
The ideal, from my end users' point of view, would be a button they
could click that would send an e-mail to an address they enter with the
data attached in .csv format. I do understand that e-mail would not be
the best way of getting the data to a web server, but that is not the
objective. Forwarding the data from my web site to a user-specified
e-mail address would require anti-spam precautions, and be generally
undesirable.
I've done web searches, and the closest I've been able to get is to fold
the data into a mailto URL as the message body, not an attachment. I
would be length limited by the Internet Explorer 2083 char URL limit,
and I think I would also have to quote URL special characters.
Another option is to just display the data and invite the user to
select and copy. The data could then be pasted into the body of an
e-mail, or into a text file in an editor window. I believe that would
work, but involves more end user busy work than is ideal.
I am very new to JavaScript, so I'm really hoping there is a better way
of doing this that I have just not found.
Thanks for any ideas or pointers to web sites I should read.
Patricia Shanahan wrote:
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format. [ ... ]
I don't understand why you would choose email for this rather than a
web download. Are the browsers working disconnected from the server
serving that content? Is the server extremely limited? If neither of
these is true, then you should be able to send the data to the server
to send back as a downloadable file. That seems the most flexible
solution. Does your infrastructure prevent this?
Scott Sauyet wrote:
> Patricia Shanahan wrote:
>> I am writing a data collection application. It needs to run on as many
>> tablets and laptops as possible, so I'm writing it in HTML and
>> JavaScript. Although I cannot ask end users to buy a particular device,
>> I can ask them to install an up to date browser.
>> The ultimate destination of the data is a spreadsheet on a workstation
>> controlled by the person doing the data entry, or one of their associates.
>> The ideal, from my end users' point of view, would be a button they
>> could click that would send an e-mail to an address they enter with the
>> data attached in .csv format. [ ... ]
> I don't understand why you would choose email for this rather than a
> web download. Are the browsers working disconnected from the server
> serving that content? Is the server extremely limited? If neither of
> these is true, then you should be able to send the data to the server
> to send back as a downloadable file. That seems the most flexible
> solution. Does your infrastructure prevent this?
I posted a proof of concept of this technique in a thread started by
this post:
> Patricia Shanahan wrote:
>> I am writing a data collection application. It needs to run on as many
>> tablets and laptops as possible, so I'm writing it in HTML and
>> JavaScript. Although I cannot ask end users to buy a particular device,
>> I can ask them to install an up to date browser.
>> The ultimate destination of the data is a spreadsheet on a workstation
>> controlled by the person doing the data entry, or one of their associates.
>> The ideal, from my end users' point of view, would be a button they
>> could click that would send an e-mail to an address they enter with the
>> data attached in .csv format. [ ... ]
> I don't understand why you would choose email for this rather than a
> web download. Are the browsers working disconnected from the server
> serving that content? Is the server extremely limited? If neither of
> these is true, then you should be able to send the data to the server
> to send back as a downloadable file. That seems the most flexible
> solution. Does your infrastructure prevent this?
It does make it much less desirable and appropriate than e-mail
transmission.
If there were a non-browser programming language and run time
environment that ran on all target devices, including iPad, I would be
writing an application in that language. The only reason for configuring
the application as a web site is the number of possible collection
devices that have browsers with JavaScript.
The data is not my data and is none of my business. Different people
will be doing the data collection, for different projects, in different
organizations. Each project will belong to some researcher who will
typically use a workstation behind a firewall to consolidate and process
the data and prepare reports based on it.
I would like to get the data as directly as possible from the data
collection device to that workstation. The end users are expert
spreadsheet users, so they know what to do with a .csv attachment, but
are not web developers and do not necessarily control a web server. My
lead user suggested e-mail as his ideal data delivery method.
Some of the data collection will have to be done offline. I'm looking at
marking pages and JavaScript files for offline use, but would like to
also offer the application in the form of a zip file that can be
downloaded and extracted on a collection device, and used locally. I
plan to store the data in the browser's local memory until the user has
network access. Transferring data collected by local pages to my web
site gets into cross-domain access issues.
> Scott Sauyet wrote:
>> Patricia Shanahan wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>> The ultimate destination of the data is a spreadsheet on a workstation
>>> controlled by the person doing the data entry, or one of their associates.
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>> I don't understand why you would choose email for this rather than a
>> web download. Are the browsers working disconnected from the server
>> serving that content? Is the server extremely limited? If neither of
>> these is true, then you should be able to send the data to the server
>> to send back as a downloadable file. That seems the most flexible
>> solution. Does your infrastructure prevent this?
> I posted a proof of concept of this technique in a thread started by
> this post:
I've looked at the thread. If I understand it correctly, it is about
getting the data to the web site serving the pages, not to an e-mail
inbox on a workstation outside that domain, my objective. I recognize
that there may be ways of forwarding the data, but I would prefer to
avoid that if there is any way of doing so.
Patricia Shanahan wrote:
Scott Sauyet wrote:
>> Patricia Shanahan wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>> The ultimate destination of the data is a spreadsheet on a workstation
>>> controlled by the person doing the data entry, or one of their associates.
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
>> I don't understand why you would choose email for this rather than a
>> web download. Are the browsers working disconnected from the server
>> serving that content? Is the server extremely limited? If neither of
>> these is true, then you should be able to send the data to the server
>> to send back as a downloadable file. That seems the most flexible
>> solution. Does your infrastructure prevent this?
> It does make it much less desirable and appropriate than e-mail
> transmission.
> If there were a non-browser programming language and run time
> environment that ran on all target devices, including iPad, I would be
> writing an application in that language. The only reason for configuring
> the application as a web site is the number of possible collection
> devices that have browsers with JavaScript.
I see. I did misunderstand the problem. I don't think you will be
able to do what you would like. Client-side Javascript has no
capability to email. `mailto:` links are just ways to launch external
email programs, and there is no way that I know of to add attachments
to those emails.
Patricia Shanahan wrote:
> Scott Sauyet wrote:
>> Scott Sauyet wrote:
>>> Patricia Shanahan wrote:
>>>> [ ... ]
>>>> The ultimate destination of the data is a spreadsheet on a workstation
>>>> controlled by the person doing the data entry, or one of their associates.
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>>> I don't understand why you would choose email for this rather than a
>>> web download. Are the browsers working disconnected from the server
>>> serving that content? Is the server extremely limited? If neither of
>>> these is true, then you should be able to send the data to the server
>>> to send back as a downloadable file. That seems the most flexible
>>> solution. Does your infrastructure prevent this?
>> I posted a proof of concept of this technique in a thread started by
>> this post:
> I've looked at the thread. If I understand it correctly, it is about
> getting the data to the web site serving the pages, not to an e-mail
> inbox on a workstation outside that domain, my objective. I recognize
> that there may be ways of forwarding the data, but I would prefer to
> avoid that if there is any way of doing so.
You are correct. This is an example of how you can do web downloads
from client-side code with a minimally cooperative server, not how to
do any email. It will not work at all in an off-line environment, and
it does require that the users trust the server not to do anything
more with the data than to return it as a download.
I wish I had a suggestion that might help with your original problem,
but I don't know of anything. My best suggestion would be to write
something that you could compile for each of your target
environments. If you want client-side Javascript, you might try
something that supplies its UI over HTTP and then launch a browser
pointing to a local host, but even then you would need to write that
host in something that you could deploy natively to your target
machines. Sorry.
> Patricia Shanahan wrote:
...
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
> I see. I did misunderstand the problem. I don't think you will be
> able to do what you would like. Client-side Javascript has no
> capability to email. `mailto:` links are just ways to launch external
> email programs, and there is no way that I know of to add attachments
> to those emails.
> I wish I had better news for you. Best of luck,
Thanks. Even a negative result is very helpful. I would otherwise have
spent a lot of time web searching and experimenting looking for
something that does not exist. It is relatively easy to find how to do
something that can be done in an unfamiliar language. Being sure
something cannot be done is much harder.
I do have a fall-back position that would have to be used to in some
situations. I plan to provide a way to display the data in a text area,
ideally already selected, so that the user can copy it to the clipboard.
Once it is in the clipboard it can be pasted into an e-mail, Google docs
text file, text file on a thumb drive etc. etc.
I have to support that anyway for devices that do not have an e-mail
client, and for confidential data that should not be sent over the
Internet in unencrypted form.
js or html cannot send an e-mail as an engine from the browser, true, however a mail-server on the server side can do the sending, if the webpage just provides the FORM with a method say method="post" and can also take file(s) <input type="file" ...> input to be send over on with enctype="multipar/form-data" in the FORM. The only thing needed for all that will be the mail-server service on the server side and the script to process it.
"Patricia Shanahan" <p...@acm.org> wrote:
>>> I am writing a data collection application. It needs to run on as many
>>> tablets and laptops as possible, so I'm writing it in HTML and
>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>> I can ask them to install an up to date browser.
>>> The ideal, from my end users' point of view, would be a button they
>>> could click that would send an e-mail to an address they enter with the
>>> data attached in .csv format. [ ... ]
> If there were a non-browser programming language and run time
> environment that ran on all target devices, including iPad, I would be
> writing an application in that language. The only reason for configuring
> the application as a web site is the number of possible collection
> devices that have browsers with JavaScript.
> I would like to get the data as directly as possible from the data
> collection device to that workstation. The end users are expert
> spreadsheet users, so they know what to do with a .csv attachment, but
> are not web developers and do not necessarily control a web server. My
> lead user suggested e-mail as his ideal data delivery method.
Forgive if I got it wrong: data is collected on devices with internet access and browser support.
This data is in the form of tables or files and needs to be sent to someone with an email account, where the account depends on the device/data under consideration. You would like to get it there 'as direct as possible'.
Suppose you had a web server. The person operating the collection device surfs to its URL. He gets a webpage with two selection 'fields': one to indicate where the data is (when it is a file) or to copy it into a text field (when it is a table). The other to select the email address of the target person. Any pre-processing (like getting the data in the right format) could be done by script on the page.
'Submit' could then result in an (encrypted) upload to the server, where the data is attached to an email which the server sends to the target.
Would that meet your requirements? It would be easy to implement.
Tom
> "Patricia Shanahan" <p...@acm.org> wrote:
>>>> I am writing a data collection application. It needs to run on as many
>>>> tablets and laptops as possible, so I'm writing it in HTML and
>>>> JavaScript. Although I cannot ask end users to buy a particular device,
>>>> I can ask them to install an up to date browser.
>>>> The ideal, from my end users' point of view, would be a button they
>>>> could click that would send an e-mail to an address they enter with the
>>>> data attached in .csv format. [ ... ]
>> If there were a non-browser programming language and run time
>> environment that ran on all target devices, including iPad, I would be
>> writing an application in that language. The only reason for configuring
>> the application as a web site is the number of possible collection
>> devices that have browsers with JavaScript.
>> I would like to get the data as directly as possible from the data
>> collection device to that workstation. The end users are expert
>> spreadsheet users, so they know what to do with a .csv attachment, but
>> are not web developers and do not necessarily control a web server. My
>> lead user suggested e-mail as his ideal data delivery method.
> Forgive if I got it wrong: data is collected on devices with internet access
> and browser support.
> This data is in the form of tables or files and needs to be sent to someone
> with an email account, where the account depends on the device/data under
> consideration. You would like to get it there 'as direct as possible'.
Typically, the data will be in the browser's local storage, where I can
put it from client-side JavaScript. However, the main point is that the
data will be somewhere accessible to my client side code.
> Suppose you had a web server. The person operating the collection device
> surfs to its URL. He gets a webpage with two selection 'fields': one to
> indicate where the data is (when it is a file) or to copy it into a text
> field (when it is a table). The other to select the email address of the
> target person. Any pre-processing (like getting the data in the right
> format) could be done by script on the page.
> 'Submit' could then result in an (encrypted) upload to the server, where the
> data is attached to an email which the server sends to the target.
> Would that meet your requirements? It would be easy to implement.
How safe would that be from spammers wanting to turn my web site into a
forwarding engine?
Patricia Shanahan wrote:
> I am writing a data collection application. It needs to run on as many
> tablets and laptops as possible, so I'm writing it in HTML and
> JavaScript. Although I cannot ask end users to buy a particular device,
> I can ask them to install an up to date browser.
> The ultimate destination of the data is a spreadsheet on a workstation
> controlled by the person doing the data entry, or one of their associates.
> The ideal, from my end users' point of view, would be a button they
> could click that would send an e-mail to an address they enter with the
> data attached in .csv format.
You cannot do that client-side, so you will have to do it server-side. That is, have a server-side application compile the .csv and send the e-mail.
Usually that would be the same server-side application that generated the client-side application in the first place.
> I do understand that e-mail would not be the best way of getting the data
> to a web server, but that is not the objective. Forwarding the data from
> my web site to a user-specified e-mail address would require anti-spam
> precautions, and be generally undesirable.
If that is a concern, users of the application need to be authenticated before they can use that function (see also [OWASP]).
Only shifting the load from the server to the client is not a solution. In fact, it has the potential to make matters worse. Client computers (including mobile devices) are usually much less protected, thus more easily compromised, than servers.
> I've done web searches, and the closest I've been able to get is to fold
> the data into a mailto URL as the message body, not an attachment.
Technically, an e-mail attachment is a part of the message body of a multi-
part message, following a delimiter line, own header and usually a Base64-
encoded message-part body (see [RFC2046]); so, in theory, it could work.
But I would not recommend it for production. In fact, security measures might prevent it.
> I would be length limited by the Internet Explorer 2083 char URL limit,
> and I think I would also have to quote URL special characters.
Apparently there are exceptions for certain supported URI schemes, such as `data:'. [SO] There might be one for `mailto:' as well. However, a suitable MUA will need to be installed and configured at the client for this to work, which you should not make a requirement.
> Another option is to just display the data and invite the user to
> select and copy. The data could then be pasted into the body of an
> e-mail, or into a text file in an editor window. I believe that would
> work, but involves more end user busy work than is ideal.
Yes, in a Web application you should make best use of the *Web* first.
> I am very new to JavaScript, so I'm really hoping there is a better way
> of doing this that I have just not found.
Client-side there is nothing better than that, but it does not mean that it cannot be done using an ECMAScript implementation server-side.
[RFC2046]
Freed, N., Borenstein, N.: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. November 1996. <http://tools.ietf.org/html/rfc2046>
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
...
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.
> But I would not recommend it for production. In fact, security measures > might prevent it.
...
It does sound worth investigating.
>> Another option is to just display the data and invite the user to
>> select and copy. The data could then be pasted into the body of an
>> e-mail, or into a text file in an editor window. I believe that would
>> work, but involves more end user busy work than is ideal.
> Yes, in a Web application you should make best use of the *Web* first.
I'm not writing a web application.
I'm writing an application that happens to be implemented in HTML and
JavaScript, and use a browser as the run time. If iPad had a suitable
Java runtime, and a less inconvenient development process, it would have
been a Java application. Because of the choice of languages, one way of
deploying it is to use HTTP to get the files from some server. For other
combinations of situation and device, it may be better to download the
application to the client file system.
In comp.lang.javascript message <JqadnXQNAdXTHffNnZ2dnUVZ_qSdnZ2d@earthl
ink.com>, Mon, 1 Oct 2012 22:49:04, Patricia Shanahan <p...@acm.org>
posted:
>I am writing a data collection application. It needs to run on as many
>tablets and laptops as possible, so I'm writing it in HTML and
>JavaScript. Although I cannot ask end users to buy a particular device,
>I can ask them to install an up to date browser.
> ...
I see no reason why you should not offer more than one method.
You can display the data, and the address, etc., and invite the user to
copy'n'paste into their ordinary E-mail system. Ensure that the data
fits in 72 characters per line, with newlines between, and uses only
7-bit characters, and has a data delimiter before and after, and it
should be possible to extract it reliably from a received E-mail. That
should all be easy for you to arrange.
You can then develop some other method, perhaps using code on the server
to forward the message; and once it is working you can allow users to do
that instead.
Some users might refer E-mail, as giving them a record of what was sent
when in a "filing system" that they already have.
But, as "someone new to JavaScript", your first thought should be to
find a confederate who already knows the language. Advertise in your
village magazine; look for scripted web pages that are local to your
town; employ a local firm who knows about such things, or whatever.
Remember that the fact that any idiot can start writing JavaScript
inevitably means that a large number of them have done so.
In comp.lang.javascript,
Dr J R Stockton <reply1...@merlyn.demon.co.uk.invalid> wrote:
> You can display the data, and the address, etc., and invite the user to
> copy'n'paste into their ordinary E-mail system. Ensure that the data
> fits in 72 characters per line, with newlines between, and uses only
> 7-bit characters, and has a data delimiter before and after, and it
> should be possible to extract it reliably from a received E-mail. That
> should all be easy for you to arrange.
If the poster does go down that route, be aware that whitespace
get mangled in email often, so not making whitespace significant
will help to reliably extract the message. (Or make all whitespace
interchangable: one newline is as good as two spaces, etc.)
Really the simple way to do this, is format the data however you
want, then apply the standard base64 encoding to it, and add headers.
The message will look a lot like a raw mail attachment, or a PGP
encypted block, or a SSL certificate, or ...
Elijah
------
the space issue sometimes came up with uuencode
> But, as "someone new to JavaScript", your first thought should be to
> find a confederate who already knows the language. Advertise in your
> village magazine; look for scripted web pages that are local to your
> town; employ a local firm who knows about such things, or whatever.
I think "new to JavaScript" may have been ambiguous. I am not new to
programming, or to learning programming languages, just to JavaScript. I
have over 30 years professional programming experience and a doctorate
in computer science. I have studied many programming languages, starting
with Fortran in 1967.
Usually, when I decide a program I want to write should be in a language
I don't already know my first thought is to get reading and writing. I
read books, tutorials, specifications, newsgroups, newsgroup FAQs, and
existing code. I write short practice programs, starting with the
basics, but after a couple of weeks of learning JavaScript I'm on to
experimenting with some of the difficulties I need to solve.
Is JavaScript especially difficult to learn?
It does combine a lot of features, but I have not yet encountered a
completely new feature, as distinct from variations on ideas I already
understand. Even the browser incompatibility issue reminds me of the
state of Fortran in the early 1980's.
Eli the Bearded wrote:
> In comp.lang.javascript,
> Dr J R Stockton <reply1...@merlyn.demon.co.uk.invalid> wrote:
>> You can display the data, and the address, etc., and invite the user to
>> copy'n'paste into their ordinary E-mail system. Ensure that the data
>> fits in 72 characters per line, with newlines between, and uses only
>> 7-bit characters, and has a data delimiter before and after, and it
>> should be possible to extract it reliably from a received E-mail. That
>> should all be easy for you to arrange.
> If the poster does go down that route, be aware that whitespace
> get mangled in email often, so not making whitespace significant
> will help to reliably extract the message. (Or make all whitespace
> interchangable: one newline is as good as two spaces, etc.)
> Really the simple way to do this, is format the data however you
> want, then apply the standard base64 encoding to it, and add headers.
> The message will look a lot like a raw mail attachment, or a PGP
> encypted block, or a SSL certificate, or ...
The whitespace issue is a good point against sending the data unencoded.
The data is spreadsheet-like, and needs to end up in a spreadsheet, so
csv is the obvious text format, but newlines are significant. Breaking a
long line into two shorter lines would create two spreadsheet rows where
there should be one.
Patricia Shanahan wrote:
> The data is spreadsheet-like, and needs to end up in a spreadsheet, so
> csv is the obvious text format, but newlines are significant. Breaking a
> long line into two shorter lines would create two spreadsheet rows where
> there should be one.
For this and other similar reasons, the body of an email is almost
certainly a terrible transport medium for the data you describe. You
could use email attachments, but as already discussed, that probably
won't be possible with client-side Javascript.
Patricia Shanahan wrote:
> I think "new to JavaScript" may have been ambiguous. I am not new to
> programming, or to learning programming languages, just to JavaScript. I
> have over 30 years professional programming experience and a doctorate
> in computer science. I have studied many programming languages, starting
> with Fortran in 1967.
> [ ... ]
> Is JavaScript especially difficult to learn?
No it is not. There are difficulties in browser-scripting because of
the incompatibilities, but there is nothing particularly challenging
about the language. But, if you're familiar with C-style languages,
it's easy to expect this one to act more like those than it does just
because of syntactic similarity.
Assuming you have experience with a language that has functional
aspect, whether pure functional like ML or Haskell, or ones that have
major functional techniques like LISP or Scheme, then you should be
able to quickly grasp a big part of how the language differs from ones
like Java or C#. The only other really unusual major aspect of the
language is is prototypal inheritance.
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
..
>> I've done web searches, and the closest I've been able to get is to fold
>> the data into a mailto URL as the message body, not an attachment.
> Technically, an e-mail attachment is a part of the message body of a multi-
> part message, following a delimiter line, own header and usually a Base64-
> encoded message-part body (see [RFC2046]); so, in theory, it could work.
> But I would not recommend it for production. In fact, security measures > might prevent it.
I've done some more web searches and experiments. Unfortunately, the
comment about security measures seems to be correct.
RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
fields such as Subject and Keywords, as well as Body, are believed to be
both safe and useful in the general case."
I've tested with Firefox as browser and Thunderbird as mail client. The
content type header in the message as delivered is "text/plain;
charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
a multi-part content type in the URI.
Patricia Shanahan wrote:
> RFC 6068, "The 'mailto' URI Scheme" says "Only a limited set of header
> fields such as Subject and Keywords, as well as Body, are believed to be
> both safe and useful in the general case."
> I've tested with Firefox as browser and Thunderbird as mail client. The
> content type header in the message as delivered is "text/plain;
> charset=ISO-8859-1; format=flowed" regardless of my attempts to specify
> a multi-part content type in the URI.
I had not considered the requirement for the main `Content-Type' header field of multi-part messages.
The question remains why it would be acceptable to send the data over the Internet via e-mail to an SMTP server, but not over the Internet to an HTTP server.
> The question remains why it would be acceptable to send the data over the > Internet via e-mail to an SMTP server, but not over the Internet to an HTTP > server.
The difference is that most tablets already have access to an existing
SMTP server, and any SMTP server, without special configuration, can
forward e-mail to some mailbox that can be accessed from the workstation
where that particular data set will be processed.
On the other hand, organizations using the software are unlikely to have
an HTTP server set up with the right scripts. Typically, the department
that might use the software I'm writing will not have the sort of
control over a server that it takes to install new scripts on it.
I could install scripts in my personal domain, but I don't think users
would want their data to go through my domain.
Patricia Shanahan wrote:
> Thomas 'PointedEars' Lahn wrote:
>> The question remains why it would be acceptable to send the data over the
>> Internet via e-mail to an SMTP server, but not over the Internet to an
>> HTTP server.
> The difference is that most tablets already have access to an existing
> SMTP server, and any SMTP server, without special configuration, can
> forward e-mail to some mailbox that can be accessed from the workstation
> where that particular data set will be processed.
> On the other hand, organizations using the software are unlikely to have
> an HTTP server set up with the right scripts. Typically, the department
> that might use the software I'm writing will not have the sort of
> control over a server that it takes to install new scripts on it.
> I could install scripts in my personal domain, but I don't think users
> would want their data to go through my domain.
ACK. Alternative approaches can be suggested if you describe your problem in more detail:
PointedEars
-- Sometimes, what you learn is wrong. If those wrong ideas are close to the root of the knowledge tree you build on a particular subject, pruning the bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>
Thomas 'PointedEars' Lahn wrote:
> Patricia Shanahan wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> The question remains why it would be acceptable to send the data over the
>>> Internet via e-mail to an SMTP server, but not over the Internet to an
>>> HTTP server.
>> The difference is that most tablets already have access to an existing
>> SMTP server, and any SMTP server, without special configuration, can
>> forward e-mail to some mailbox that can be accessed from the workstation
>> where that particular data set will be processed.
>> On the other hand, organizations using the software are unlikely to have
>> an HTTP server set up with the right scripts. Typically, the department
>> that might use the software I'm writing will not have the sort of
>> control over a server that it takes to install new scripts on it.
>> I could install scripts in my personal domain, but I don't think users
>> would want their data to go through my domain.
> ACK. Alternative approaches can be suggested if you describe your problem > in more detail:
I cannot describe my current project in public until it is further
along. I'm not asking for general help with my program design. That's my
problem.
I just wanted to check whether a specific user requirement could be met
using only HTML and JavaScript, after I had failed to find a solution by
reading books, web searching, thinking, and experiments. As I indicated
in my first article, I was fully aware of server based solutions, but
they are not appropriate for my application.
I've got the answer to my question - I can only send text in an e-mail -
so I'm on to working with that answer.
I don't think it is a big enough problem to make me change strategy from
HTML + JavaScript to installable application implementations for each
major group of environments.
> I could install scripts in my personal domain, but I don't think users
> would want their data to go through my domain.
They're already trusting your app to handle their data properly, so why
would they worry about the forwarding server? In the usual case, the
script doing the web-to-mail forwarding will be a very simple affair.
You can make it available as an open source download for those who do
have a server, and provide forwarding on own server as a (free?) service.
I think sending attachments by email with JS alone (from an HTML
document in a browser) is a lost cause, especially if it has to work on
as many clients as possible. It's not that the language is too limited,
the problem is that browsers don't usually expose that kind of
functionality to scripts (and for good reason).
Even Java applets can't send emails to random SMTP servers. In theory,
they'd be powerful enough (for example with JavaMail, or by just opening
a socket and speaking SMTP directly), but the default security
restrictions will prevent them from connecting to anything but the
originating host.
From what I understand about your project, you have two options: the
HTML+JS approach you described plus a server-side component, or you bite
the bullet and build native apps for each target platform. You could
still do most of the layout/navigation parts in HTML+JS, but your app
will have to handle the email part.
