Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

I've got the following problem. I'm a biologist and I have a device at work
which monitors my frog habitat. The device has a bunch of sensors, and runs
an embedded html server with some java functions defined which know how to
read the hardware sensorts. I access it from wherever I am via any browser,
and it displays the measurements (a set of simple numbers) as Java applets
in a simple html page. One entry in this page (a table cell) looks like
this:

<td align="center"><font size="6">
<applet codeBase=/java height=50 width=100 code="display">
PARAM NAME="channel" VALUE="IN1A">
<param NAME="interval" VALUE="1">
<param NAME="fontsize" VALUE="22">
</applet></font></td>

All this works fine from any browser running on a regular computer - the
code shows me the numbers in real time (temperature, etc.). Now, I need to
be able to check these from my pocket-PC - it's a PDA phone (Samsung i700)
and while it has a couple of browsers on it, none of them are able to handle
the real-time java (if I've missed one which does, please let me know!).
However, the device does run a great secure telnet application (SSH) which I
can use to log into my office computer (a G5 Mac running OSX Panther). So,
what I'm thinking is this. What if I run some sort of program (a background
process which would be active all the time) on my Mac at work, which would
access the real-time device through its URL, get the measurements, and write
them to a text file. The text file could then be viewed using any simple
browser from my PDA, or just printed if I logged in remotely via telnet.
This wouldn't be quite real-time, but good enough, if it updated the static
file every 10 minutes or so. So, can anyone help me write such a piece of
code? It should be fairly easy I think (perl or C), but I don't have any
experience with java. What I need is a simple program which, every few
minutes, would get the html file from a specified URL, parse the output of
the several java calls embedded in the html (each one is a floating-point
number), and write it to a text file. The part I don't know how to do is how
to get a C program to have access to the output of the java output. Any
thoughts would be greatly appreciated! Thanks in advance.

--

Mike Levin
mlevin77@comcast.net

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

Seems like the simplest approach would be to write additional code that
would generate and update a daily text log on the site... simply enter
the url of that log and download or view it.

Beverly Howard [MS MVP-Mobile Devices]

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

I second this approach. Use either the log4j or CommonsLogging frame work.
You can then specify EXACTLY how you want the output to look.
Both log4j and CommonsLogging are apache projects. It's pretty simple.


Beverly Howard [Ms-MVP/MobileDev] wrote:
> Seems like the simplest approach would be to write additional code that
> would generate and update a daily text log on the site... simply enter
> the url of that log and download or view it.
>
> Beverly Howard [MS MVP-Mobile Devices]
>

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

On 6/19/04 6:03 PM, in article KK2Bc.2841$1L2.1958@fe1.texas.rr.com,
"kevinc" <kevinc@elp.rr.com> wrote:

> I second this approach. Use either the log4j or CommonsLogging frame work.
> You can then specify EXACTLY how you want the output to look.
> Both log4j and CommonsLogging are apache projects. It's pretty simple.
>
>
> Beverly Howard [Ms-MVP/MobileDev] wrote:
>> Seems like the simplest approach would be to write additional code that
>> would generate and update a daily text log on the site... simply enter
>> the url of that log and download or view it.
>>
>> Beverly Howard [MS MVP-Mobile Devices]

Hi, and thanks for replying! Are you suggesting that I write code to be
run on the device itself (the box with the embedded web server and the
sensors)? If so, then it's impossible - the thing is in firmware, and cannot
(as far as I know) be modified by the user. The device is bought
off-the-shelf, with the server already burned onto the board. I don't know
if it's apache or not, but I don't have any way of running anything extra on
the box itself. But maybe I've misunderstood you - can log4j or
CommonsLogging be run on another computer, or does it have to be run on the
sensor box itself?

--

Mike Levin
mlevin77@comcast.net

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

Mike, the logging should go inside what ever Java code is actually
doing the "real work". Have THAT code log the results of any computation
that you are interested in.

Michael Levin wrote:
> On 6/19/04 6:03 PM, in article KK2Bc.2841$1L2.1958@fe1.texas.rr.com,
> "kevinc" <kevinc@elp.rr.com> wrote:
>
>
>>I second this approach. Use either the log4j or CommonsLogging frame work.
>>You can then specify EXACTLY how you want the output to look.
>>Both log4j and CommonsLogging are apache projects. It's pretty simple.
>>
>>
>>Beverly Howard [Ms-MVP/MobileDev] wrote:
>>
>>>Seems like the simplest approach would be to write additional code that
>>>would generate and update a daily text log on the site... simply enter
>>>the url of that log and download or view it.
>>>
>>>Beverly Howard [MS MVP-Mobile Devices]
>
>
> Hi, and thanks for replying! Are you suggesting that I write code to be
> run on the device itself (the box with the embedded web server and the
> sensors)? If so, then it's impossible - the thing is in firmware, and cannot
> (as far as I know) be modified by the user. The device is bought
> off-the-shelf, with the server already burned onto the board. I don't know
> if it's apache or not, but I don't have any way of running anything extra on
> the box itself. But maybe I've misunderstood you - can log4j or
> CommonsLogging be run on another computer, or does it have to be run on the
> sensor box itself?
>

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

Just a guess:

I presume that the embedded Java applet is loaded into the local browser
and executed by the Java Virtual Machine? If the Java applet is
executing locally, for example on you Mac, the question is then what
requests is that applet making to the embedded web server to interrogate
those sensors? We need to duplicate that on your PDA.

Could it be as simple as something like
http://embeddedserver/default.html?channel=IN1A to fetch the result from
the embedded web server?

I'd use a packet sniffer to look at outgoing requests from your PC/Mac
to find out how this Java applet gathers this information. If you had
the source code to the Java applet, then your goal would be almost complete.

Nikki

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

On 6/19/04 8:10 PM, in article cb2klc$i7s$1$8302bc10@news.demon.co.uk,
"Nikki Casali" <nikki@ncSasPali.deAmoMn.co.uk> wrote:

> Just a guess:
>
> I presume that the embedded Java applet is loaded into the local browser
> and executed by the Java Virtual Machine? If the Java applet is
> executing locally, for example on you Mac, the question is then what
> requests is that applet making to the embedded web server to interrogate
> those sensors? We need to duplicate that on your PDA.
>
> Could it be as simple as something like
> http://embeddedserver/default.html?channel=IN1A to fetch the result from
> the embedded web server?
>
> I'd use a packet sniffer to look at outgoing requests from your PC/Mac
> to find out how this Java applet gathers this information. If you had
> the source code to the Java applet, then your goal would be almost complete.
>
> Nikki

Hmmm. I looked at the html source of the page I was accessing. The only java
is this:

<td align="center"><font size="6">
<applet codeBase=/java height=50 width=100 code="display">
PARAM NAME="channel" VALUE="IN1A">
<param NAME="interval" VALUE="1">
<param NAME="fontsize" VALUE="22">
</applet></font></td>

I don't know java well, but this seems like there's nothing here - the real
work must be happening on the server side, right? I thought of posting the
URL for the page, so that anyone who had the time to take a look might see
for themselves how it worked, but I don't really want everyone on the web to
start polling my device, once the article gets saved to Google groups
archive etc...

--

Mike Levin
mlevin77@comcast.net

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

On 6/19/04 7:31 PM, in article %04Bc.2849$M96.362@fe2.texas.rr.com, "kevinc"
<kevinc@elp.rr.com> wrote:

> Mike, the logging should go inside what ever Java code is actually
> doing the "real work". Have THAT code log the results of any computation
> that you are interested in.

as I understand it, the real work is done in the firmware of the box - I
have no way to change that code unfortunately...

Mike

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

In article <BCFA5806.18EAD%mlevin77@comcast.net>,
Michael Levin <mlevin77@comcast.net> wrote:

> Hmmm. I looked at the html source of the page I was accessing. The only java
> is this:
>
> <td align="center"><font size="6">
> <applet codeBase=/java height=50 width=100 code="display">
> PARAM NAME="channel" VALUE="IN1A">
> <param NAME="interval" VALUE="1">
> <param NAME="fontsize" VALUE="22">
> </applet></font></td>
>
> I don't know java well, but this seems like there's nothing here - the real
> work must be happening on the server side, right? I thought of posting the
> URL for the page, so that anyone who had the time to take a look might see
> for themselves how it worked, but I don't really want everyone on the web to
> start polling my device, once the article gets saved to Google groups
> archive etc...

In Terminal, if you type:

curl "http://www.apple.com/developer/"

then it dumps to the standard output (the terminal window) the text that
the server at www.apple.com returned.

What happens when you try this with your miniserver?

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

Michael Levin <mlevin77@comcast.net> wrote:

> On 6/19/04 7:31 PM, in article %04Bc.2849$M96.362@fe2.texas.rr.com,
> "kevinc" <kevinc@elp.rr.com> wrote:
>
> > Mike, the logging should go inside what ever Java code is actually doing
> > the "real work". Have THAT code log the results of any computation that
> > you are interested in.
>
> as I understand it, the real work is done in the firmware of the box - I
> have no way to change that code unfortunately...

So it seems to me that short of hacking the data requests sent by the
Java applet, like someone else suggested, you might try and contact the
folks who make the sensor/server, and request a fix. They'd probably be
jazzed to know that someone wants to use a *phone* to monitor data
acquisition, and would come up with a solution.

Short of that, I'd wager that the Java app displays the data outside the
realm of HTML. That is, if you view the source of the web page, it won't
show you the data, just the code to display the applet.

This means you likely can't extract it from the source of the web page;
if you need this information from a web browser that doesn't do Java,
you could have your Mac load the page and then take a screen shot of the
data you need to see.

This would work as a shell script that gets run every time you request
the page. This could be as a cgi-bin shell script or Perl or PHP or
whatever. Your script would call the screencapture tool on the Mac,
like:

screencapture -x ~/myscreencapture.pdf

(-x added because otherwise your computer would make a noise every time
the page was loaded. Run screencapture from the Terminal to find out
what else it can do.)

If your PDA can't do PDF, or if you'd just prefer not to, you can
install ImageMagick via fink and have it do a conversion to jpg (and/or
crop the image, too, if you know the Java applet will be in a given
spot). This happens with the 'convert' tool. :-)

HTH.

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

That's just the HTML call that tells the client PC/Mac how to execute
the Java and where it can be downloaded from. That isn't THE Java.

The Java program being run here is called "display". That gets
downloaded from your embedded webserver, from directory "java", and then
is executed on your Mac, never on the embedded webserver.

The work of "display" is to ask for the data from "channel" at specific
"interval"s, from your server.

Ultimately, you want to bypass "display" altogether by finding out what
TCP/IP requests it is making and do those yourself.

Nikki

Michael Levin wrote:
> On 6/19/04 8:10 PM, in article cb2klc$i7s$1$8302bc10@news.demon.co.uk,

>
> Hmmm. I looked at the html source of the page I was accessing. The only java
> is this:
>
> <td align="center"><font size="6">
> <applet codeBase=/java height=50 width=100 code="display">
> PARAM NAME="channel" VALUE="IN1A">
> <param NAME="interval" VALUE="1">
> <param NAME="fontsize" VALUE="22">
> </applet></font></td>
>
> I don't know java well, but this seems like there's nothing here - the real
> work must be happening on the server side, right? I thought of posting the
> URL for the page, so that anyone who had the time to take a look might see
> for themselves how it worked, but I don't really want everyone on the web to
> start polling my device, once the article gets saved to Google groups
> archive etc...
>

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

On 6/19/04 11:34 PM, in article
oster-FC862C.20341619062004@news.sf.sbcglobal.net, "David Phillip Oster"
<oster@ieee.org> wrote:

> In Terminal, if you type:
>
> curl "http://www.apple.com/developer/"
>
> then it dumps to the standard output (the terminal window) the text that
> the server at www.apple.com returned.
>
> What happens when you try this with your miniserver?

When I do curl "http://www.apple.com/developer/", I get back the html of
that site - not the text as a browser (like lynx for example) would see it.
I tried doing this to my miniserver, and got back a bunch of html which
looks a lot like (maybe is identical to) the html of the page that my
browser would see. But, unfortunately, it does not contain the values I need
(output of the java) - only the static html around them...


--

Mike Levin
mlevin77@comcast.net

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

On 6/20/04 7:02 AM, in article 1gfns6d.1pmr7k07vwdf6N%usenet@mile23.c0m,
"Paul Mitchum" <usenet@mile23.c0m> wrote:

> So it seems to me that short of hacking the data requests sent by the
> Java applet, like someone else suggested, you might try and contact the
> folks who make the sensor/server, and request a fix. They'd probably be
> jazzed to know that someone wants to use a *phone* to monitor data
> acquisition, and would come up with a solution.

yep; I've tried that route. I can barely get those guys to fix some of the
firmware bugs that exist right now... Jazzed they might be, but I can't hold
my breath until they do it...

> Short of that, I'd wager that the Java app displays the data outside the
> realm of HTML. That is, if you view the source of the web page, it won't
> show you the data, just the code to display the applet.

yep - that's exactly right. The source looks like this:

<td align="center"><font size="6">
<applet codeBase=/java height=50 width=100 code="display">
PARAM NAME="channel" VALUE="IN1A">
<param NAME="interval" VALUE="1">
<param NAME="fontsize" VALUE="22">
</applet></font></td>

> This means you likely can't extract it from the source of the web page;
> if you need this information from a web browser that doesn't do Java,
> you could have your Mac load the page and then take a screen shot of the
> data you need to see.
> This would work as a shell script that gets run every time you request
> the page. This could be as a cgi-bin shell script or Perl or PHP or
> whatever. Your script would call the screencapture tool on the Mac,
> like:
> screencapture -x ~/myscreencapture.pdf
> (-x added because otherwise your computer would make a noise every time
> the page was loaded. Run screencapture from the Terminal to find out
> what else it can do.)
> If your PDA can't do PDF, or if you'd just prefer not to, you can
> install ImageMagick via fink and have it do a conversion to jpg (and/or
> crop the image, too, if you know the Java applet will be in a given
> spot). This happens with the 'convert' tool. :-)

That's a good idea; the only downside is that the Mac would always have to
have an open browser window going. It would sure be good if I could download
a few bytes of numbers generated in background, instead of a JPG file taken
of my whole screen. I'll keep looking for that, and if that can't happen,
I'll go with the screen capture. Thanks!

--

Mike Levin
mlevin77@comcast.net

Archived from groups: comp.sys.mac.programmer.tools,comp.sys.mac.programmers.misc,comp.lang.java,microsoft.public.pocketpc (More info?)

On 6/20/04 9:03 AM, in article cb41uk$5o$1$830fa79f@news.demon.co.uk, "Nikki
Casali" <nikki@ncSasPali.deAmoMn.co.uk> wrote:

> That's just the HTML call that tells the client PC/Mac how to execute
> the Java and where it can be downloaded from. That isn't THE Java.
>
> The Java program being run here is called "display". That gets
> downloaded from your embedded webserver, from directory "java", and then
> is executed on your Mac, never on the embedded webserver.
>
> The work of "display" is to ask for the data from "channel" at specific
> "interval"s, from your server.
>
> Ultimately, you want to bypass "display" altogether by finding out what
> TCP/IP requests it is making and do those yourself.

aha! That makes a lot of sense. Great. Is there a way to get a look at the
code of this "display"? I guess if I stare at it long enough I should be
able to figure out what it's doing and make a different version which does
what I want (dump the output into a text file). How do I get my browser to
show me the contents of the java it's running?

Thanks!

--

Mike Levin
mlevin77@comcast.net