Re: Issue with Nokia HttpConnection.flush()

Chris B <[email protected]> Tue, 23 Jun 2009 18:32:24 +0100
Newsgroups gmane.comp.java.sun.kvm,gmane.spam.detected
Message-ID <[email protected]>
This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C9F430.F42E6AA0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

If in doubt write the headers and body out manually with =
DataOutputStream.
  ----- Original Message -----=20
  From: Ricardo Scholz=20
  To: [email protected]=20
  Sent: Tuesday, June 23, 2009 3:49 PM
  Subject: Re: Issue with Nokia HttpConnection.flush()


  Hi all, it worked. Thank you all guys for your quick replies and =
attention.

  Roger, thanx for the information. It worked for both versions =
(Motorola and Nokia) by leaving the "content-type" out, seting the =
"content-length" properly and setting the "connection" property to =
"close".

  Just for the records, in case someone else has a similar problem:


    no, You can't take influence on the transfer-encoding. Motorola uses =
chunked, Nokia doesn't. So it's an absolute must to write the =
content-length to the header for Nokia phones.=20

  So, as far as I could understand, it's up to the kvm implementation =
(for instance, manufacturers) to define the transfer-encoding when =
implementing the HttpConnection. I have no control over it.
  =20
    But why on earth do you set the content-type? In my opinion you =
should leave it out unless you really encode you data properly before =
streaming it.

  I don't know why I set the content-type. During debug phase I've tried =
several approaches, and at some point, someone suggested me to set it to =
"application/x-www-urlencoded".
  =20
    flush() doesn't influence the transfer-encoding at all. It simply =
empties the internal buffer. Besides flush ist called automatically, =
when closing a connection.

  Yes, that's what I read from the docs. But when I took away the =
'flush()' call in the Motorola version, the packages started being =
transfered in a non-chunked way. Maybe I had changed something else at =
the same time that I'm missing now, and then I misinterpreted the =
results.
  =20
    Do you close the connection? If the header says "connection: =
keep-alive", you have to do so. Otherwise the server ist waiting for =
content until tomorrrow.


  Now I set the "connection" parameter to close, and I close the =
OutputStream before calling HttpConnection.getResponseCode().=20
  =20
  Thanx again.

  Best regards,

  Ricardo.






    Ricardo Scholz schrieb:=20
      Hi All,

      There's a mistake in the first message, when I said =
HttpConnection.flush() I meant OutputStream.flush().

      Hi Chris,

      Thanx for your reply. Yes, you're right. Setting the =
content-length makes no sense if the chunked protocol prepends each =
chunk length at the beginning of the chunks. The Motorola version =
content-length is overwritten to -1, and works fine.=20

      My question is: why the Nokia version does not overwrite the =
content-length property to -1 when I call OutputStream.flush() [what =
seems to be the method that makes transfer-encoding be changed to =
chunked in the Motorola version]? Also, this method does not make the =
transfer-encoding be changed to chunked, nor actually includes the =
prepended chunks length in the message body [it seems to infuence both =
in the Motorola version].

      I can't underestand how to get control of 'chunking' turnning =
on/off. (I don't even know whether it is possible or not).

      I'll try without setting the content-length (as setting it is =
useless and makes no sense anyway ;)

      Best regards,

      Ricardo.


      On Mon, Jun 22, 2009 at 11:21 PM, Chris B <[email protected]> =
wrote:

        content-length: -1 (although I explicitly set it to the byte =
array length)
        connection: close (implicitly set)
        content-type: application/x-www-form-urlencoded (explicitly set)
        transfer-encoding: chunked (implicitly set)


        you cant have a chunked with a content length! it's one or the =
other.

          ----- Original Message -----=20
          From: Ricardo Scholz=20
          To: [email protected]=20
          Sent: Monday, June 22, 2009 9:25 PM
          Subject: Issue with Nokia HttpConnection.flush()


          Hello everybody,

          I've been trying to implement a client-server application that =
exchanges byte arrays through a HTTP connection. My client-server =
application works fine with a Motorola V3, but when I try to connect =
from a Nokia 5310 XpressMusic, the input stream in the server cannot be =
read (it comes empty). I used a software that receives the connection =
and forwards the request to the server, to see some information about =
what was being sent by the clients, so I got the information below:

          In the successful Motorola version, the header parameters are:

          content-length: -1 (although I explicitly set it to the byte =
array length)
          connection: close (implicitly set)
          content-type: application/x-www-form-urlencoded (explicitly =
set)
          transfer-encoding: chunked (implicitly set)

          and the actual data sent has the chunked formatting (the chunk =
size prepended and a zeroed chunk size to inform the end of the chunks =
sequence), as below:

          29
          3333223 =
cdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96<=93=94=95=96=97=98r=99=9A=9B
          0

          In the other hand, the unsuccessful Nokia version has the =
following header parameters:

          content-length: <the actual data length> (explicitly set)
          connection: keep alive (implicitly set)
          content-type: application/x-www-form-urlencoded (explicitly =
set)
          <no transfer-encoding parameter set>

          and the actual data sent does not have the chunked formating, =
as below:

          3333223 =
cdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96<=93=94=95=96=97=98r=99=9A=9B

          I used pretty much the networking implementation as defined in =
the API. In addition, as far as I could understand, the call to =
HttpConnection.flush() sets the transfer-encoding header parameter to =
chunked, but it only works for the Motorola version. Without it, none of =
the two versions works fine, as it seems that the server can only deal =
with chunked data.

          I've tried to find something in the Forum Nokia, KVM-Interests =
archives and Google, but without actual success.

          If you guys have any idea on how to work this around, either =
in the client application or in the server application, I'd appreciate.

          Many thanks.

          Best regards,

          Ricardo Scholz.

          --=20
          ricardo]scholz
          meantime]mobile.creations
          +55[81]8664.8665

          =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 To unsubscribe, send email to [email protected] and include in the =
body of the message "signoff KVM-INTEREST". For general help, send email =
to [email protected] and include in the body of the message "help".=20
        =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 To unsubscribe, send email to [email protected] and include in the =
body of the message "signoff KVM-INTEREST". For general help, send email =
to [email protected] and include in the body of the message "help".=20



      --=20
      ricardo]scholz
      +55[81]8664.8665
      =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 To unsubscribe, send email to [email protected] and include in the =
body of the message "signoff KVM-INTEREST". For general help, send email =
to [email protected] and include in the body of the message "help".=20


--=20
/**************************
* Roger F. H=F6sl
* ...
**************************/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D To unsubscribe, send email to =
[email protected] and include in the body of the message "signoff =
KVM-INTEREST". For general help, send email to [email protected] and =
include in the body of the message "help".=20



  --=20
  ricardo]scholz
  +55[81]8664.8665
  =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 To unsubscribe, send email to [email protected] and include in the =
body of the message "signoff KVM-INTEREST". For general help, send email =
to [email protected] and include in the body of the message "help". 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".
------=_NextPart_000_0028_01C9F430.F42E6AA0
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>If in doubt write the headers and body=20
out&nbsp;manually with DataOutputStream.</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A [email protected] =
href=3D"mailto:[email protected]">Ricardo=20
  Scholz</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
[email protected]=20
  =
href=3D"mailto:[email protected]">[email protected]</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, June 23, 2009 =
3:49=20
PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Issue with Nokia=20
  HttpConnection.flush()</DIV>
  <DIV><BR></DIV>Hi all, it worked. Thank you all guys for your quick =
replies=20
  and attention.<BR><BR>Roger, thanx for the information. It worked for =
both=20
  versions (Motorola and Nokia) by leaving the "content-type" out, =
seting the=20
  "content-length" properly and setting the "connection" property to=20
  "close".<BR><BR>Just for the records, in case someone else has a =
similar=20
  problem:<BR><BR>
  <DIV class=3Dgmail_quote>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV text=3D"#000066" bgcolor=3D"#ffffff"><FONT size=3D-1><FONT =
face=3DVerdana>no,=20
    You can't take influence on the transfer-encoding. Motorola uses =
chunked,=20
    Nokia doesn't. So it's an absolute must to write the content-length =
to the=20
    header for Nokia phones. </FONT></FONT></DIV></BLOCKQUOTE>
  <DIV><BR>So, as far as I could understand, it's up to the kvm =
implementation=20
  (for instance, manufacturers) to define the transfer-encoding when=20
  implementing the HttpConnection. I have no control over =
it.<BR>&nbsp;</DIV>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV text=3D"#000066" bgcolor=3D"#ffffff"><FONT size=3D-1><FONT=20
    face=3DVerdana></FONT></FONT><FONT size=3D-1><FONT =
face=3DVerdana>But why on earth=20
    do you set the content-type? In my opinion you should leave it out =
unless=20
    you really encode you data properly before streaming=20
  it.</FONT></FONT></DIV></BLOCKQUOTE>
  <DIV><BR>I don't know why I set the content-type. During debug phase =
I've=20
  tried several approaches, and at some point, someone suggested me to =
set it to=20
  "application/x-www-urlencoded".<BR>&nbsp;</DIV>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV text=3D"#000066" bgcolor=3D"#ffffff"><FONT size=3D-1><FONT=20
    face=3DVerdana>flush() doesn't influence the transfer-encoding at =
all. It=20
    simply empties the internal buffer. Besides flush ist called =
automatically,=20
    when closing a connection.</FONT></FONT></DIV></BLOCKQUOTE>
  <DIV><BR>Yes, that's what I read from the docs. But when I took away =
the=20
  'flush()' call in the Motorola version, the packages started being =
transfered=20
  in a non-chunked way. Maybe I had changed something else at the same =
time that=20
  I'm missing now, and then I misinterpreted the =
results.<BR>&nbsp;</DIV>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV text=3D"#000066" bgcolor=3D"#ffffff"><FONT size=3D-1><FONT =
face=3DVerdana>Do=20
    you close the connection? If the header says "connection: =
keep-alive", you=20
    have to do so. Otherwise the server ist waiting for content until=20
    tomorrrow.<BR></FONT></FONT></DIV></BLOCKQUOTE>
  <DIV><BR>Now I set the "connection" parameter to close, and I close =
the=20
  OutputStream before calling HttpConnection.getResponseCode(). <FONT=20
  size=3D-1><FONT face=3DVerdana></FONT></FONT><BR>&nbsp;<BR>Thanx=20
  again.<BR><BR>Best regards,<BR><BR>Ricardo.<BR><BR><BR></DIV>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">
    <DIV text=3D"#000066" bgcolor=3D"#ffffff"><FONT size=3D-1><FONT=20
    face=3DVerdana><BR><BR></FONT></FONT><BR>Ricardo Scholz schrieb:=20
    <DIV>
    <DIV></DIV>
    <DIV class=3Dh5>
    <BLOCKQUOTE type=3D"cite">Hi All,<BR><BR>There's a mistake in the =
first=20
      message, when I said HttpConnection.flush() I meant=20
      OutputStream.flush().<BR><BR>Hi Chris,<BR><BR>Thanx for your =
reply. Yes,=20
      you're right. Setting the content-length makes no sense if the =
chunked=20
      protocol prepends each chunk length at the beginning of the =
chunks. The=20
      Motorola version content-length is overwritten to -1, and works =
fine.=20
      <BR><BR>My question is: why the Nokia version does not overwrite =
the=20
      content-length property to -1 when I call OutputStream.flush() =
[what seems=20
      to be the method that makes transfer-encoding be changed to =
chunked in the=20
      Motorola version]? Also, this method does not make the =
transfer-encoding=20
      be changed to chunked, nor actually includes the prepended chunks =
length=20
      in the message body [it seems to infuence both in the Motorola=20
      version].<BR><BR>I can't underestand how to get control of =
'chunking'=20
      turnning on/off. (I don't even know whether it is possible or=20
      not).<BR><BR>I'll try without setting the content-length (as =
setting it is=20
      useless and makes no sense anyway ;)<BR><BR>Best=20
      regards,<BR><BR>Ricardo.<BR><BR>
      <DIV class=3Dgmail_quote>On Mon, Jun 22, 2009 at 11:21 PM, Chris B =
<SPAN=20
      dir=3Dltr>&lt;<A href=3D"mailto:[email protected]"=20
      target=3D_blank>[email protected]</A>&gt;</SPAN> wrote:<BR>
      <BLOCKQUOTE class=3Dgmail_quote=20
      style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; =
BORDER-LEFT: rgb(204,204,204) 1px solid">
        <DIV bgcolor=3D"#ffffff">
        <DIV>
        <DIV>content-length: -1 (although I explicitly set it to the =
byte array=20
        length)<BR>connection: close (implicitly set)<BR>content-type:=20
        application/x-www-form-urlencoded (explicitly =
set)<BR>transfer-encoding:=20
        chunked (implicitly set)</DIV>
        <DIV>&nbsp;</DIV>
        <DIV>&nbsp;</DIV></DIV>
        <DIV><FONT face=3DArial size=3D2>you cant have a chunked with a =
content=20
        length! it's one or the other.</FONT></DIV>
        <DIV>&nbsp;</DIV>
        <BLOCKQUOTE=20
        style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: =
5px; BORDER-LEFT: rgb(0,0,0) 2px solid; MARGIN-RIGHT: 0px">
          <DIV>
          <DIV>
          <DIV=20
          style=3D"FONT: 10pt arial; font-size-adjust: none; =
font-stretch: normal">-----=20
          Original Message ----- </DIV>
          <DIV=20
          style=3D"BACKGROUND: rgb(228,228,228) 0% 50%; FONT: 10pt =
arial; font-size-adjust: none; font-stretch: normal; =
moz-background-clip: -moz-initial; moz-background-origin: -moz-initial; =
moz-background-inline-policy: -moz-initial"><B>From:</B>=20
          <A [email protected] =
href=3D"mailto:[email protected]"=20
          target=3D_blank>Ricardo Scholz</A> </DIV>
          <DIV=20
          style=3D"FONT: 10pt arial; font-size-adjust: none; =
font-stretch: normal"><B>To:</B>=20
          <A [email protected]=20
          href=3D"mailto:[email protected]"=20
          target=3D_blank>[email protected]</A> </DIV>
          <DIV=20
          style=3D"FONT: 10pt arial; font-size-adjust: none; =
font-stretch: normal"><B>Sent:</B>=20
          Monday, June 22, 2009 9:25 PM</DIV>
          <DIV=20
          style=3D"FONT: 10pt arial; font-size-adjust: none; =
font-stretch: normal"><B>Subject:</B>=20
          Issue with Nokia HttpConnection.flush()</DIV>
          <DIV><BR></DIV>Hello everybody,<BR><BR>I've been trying to =
implement a=20
          client-server application that exchanges byte arrays through a =
HTTP=20
          connection. My client-server application works fine with a =
Motorola=20
          V3, but when I try to connect from a Nokia 5310 XpressMusic, =
the input=20
          stream in the server cannot be read (it comes empty). I used a =

          software that receives the connection and forwards the request =
to the=20
          server, to see some information about what was being sent by =
the=20
          clients, so I got the information below:<BR><BR>In the =
successful=20
          Motorola version, the header parameters =
are:<BR><BR>content-length: -1=20
          (although I explicitly set it to the byte array =
length)<BR>connection:=20
          close (implicitly set)<BR>content-type:=20
          application/x-www-form-urlencoded (explicitly=20
          set)<BR>transfer-encoding: chunked (implicitly set)<BR><BR>and =
the=20
          actual data sent has the chunked formatting (the chunk size =
prepended=20
          and a zeroed chunk size to inform the end of the chunks =
sequence), as=20
          below:<BR><BR>29<BR>3333223=20
          =
cdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96&lt;=93=94=95=96=97=98r=99=9A=9B=
<BR>0<BR><BR>In the other hand,=20
          the unsuccessful Nokia version has the following header=20
          parameters:<BR><BR>content-length: &lt;the actual data =
length&gt;=20
          (explicitly set)<BR>connection: keep alive (implicitly=20
          set)<BR>content-type: application/x-www-form-urlencoded =
(explicitly=20
          set)<BR>&lt;no transfer-encoding parameter set&gt;<BR><BR>and =
the=20
          actual data sent does not have the chunked formating, as=20
          below:<BR><BR>3333223 =
cdefghijkb=96=9F5=A9=A6=9C=936=93=94=95=96&lt;=93=94=95=96=97=98r=99=9A=9B=
<BR><BR>I=20
          used pretty much the networking implementation as defined in =
the API.=20
          In addition, as far as I could understand, the call to=20
          HttpConnection.flush() sets the transfer-encoding header =
parameter to=20
          chunked, but it only works for the Motorola version. Without =
it, none=20
          of the two versions works fine, as it seems that the server =
can only=20
          deal with chunked data.<BR><BR>I've tried to find something in =
the=20
          Forum Nokia, KVM-Interests archives and Google, but without =
actual=20
          success.<BR><BR>If you guys have any idea on how to work this =
around,=20
          either in the client application or in the server application, =
I'd=20
          appreciate.<BR><BR>Many thanks.<BR><BR>Best =
regards,<BR><BR>Ricardo=20
          Scholz.<BR><BR>--=20
          =
<BR>ricardo]scholz<BR>meantime]mobile.creations<BR>+55[81]8664.8665<BR></=
DIV></DIV>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=20
          To unsubscribe, send email to <A =
href=3D"mailto:[email protected]"=20
          target=3D_blank>[email protected]</A> and include in the =
body of the=20
          message "signoff KVM-INTEREST". For general help, send email =
to <A=20
          href=3D"mailto:[email protected]"=20
          target=3D_blank>[email protected]</A> and include in the =
body of the=20
          message "help".=20
        =
</BLOCKQUOTE></DIV>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=20
        To unsubscribe, send email to <A =
href=3D"mailto:[email protected]"=20
        target=3D_blank>[email protected]</A> and include in the =
body of the=20
        message "signoff KVM-INTEREST". For general help, send email to =
<A=20
        href=3D"mailto:[email protected]"=20
        target=3D_blank>[email protected]</A> and include in the =
body of the=20
        message "help". </BLOCKQUOTE></DIV><BR><BR clear=3Dall><BR>--=20
      =
<BR>ricardo]scholz<BR>+55[81]8664.8665<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
      To unsubscribe, send email to <A =
href=3D"mailto:[email protected]"=20
      target=3D_blank>[email protected]</A> and include in the body =
of the=20
      message "signoff KVM-INTEREST". For general help, send email to <A =

      href=3D"mailto:[email protected]"=20
      target=3D_blank>[email protected]</A> and include in the body =
of the=20
      message "help". </BLOCKQUOTE><BR></DIV></DIV><FONT =
color=3D#888888><PRE cols=3D"72">--=20
/**************************
* Roger F. H=F6sl
* ...
**************************/</PRE></FONT></DIV>
    <DIV>
    <DIV></DIV>
    <DIV=20
    =
class=3Dh5>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=20
    To unsubscribe, send email to <A =
href=3D"mailto:[email protected]"=20
    target=3D_blank>[email protected]</A> and include in the body of =
the=20
    message "signoff KVM-INTEREST". For general help, send email to <A=20
    href=3D"mailto:[email protected]" =
target=3D_blank>[email protected]</A>=20
    and include in the body of the message "help".=20
  </DIV></DIV></BLOCKQUOTE></DIV><BR><BR clear=3Dall><BR>--=20
  =
<BR>ricardo]scholz<BR>+55[81]8664.8665<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
  To unsubscribe, send email to [email protected] and include in the =
body of=20
  the message "signoff KVM-INTEREST". For general help, send email to=20
  [email protected] and include in the body of the message "help".=20
</BLOCKQUOTE></BODY></HTML>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".

------=_NextPart_000_0028_01C9F430.F42E6AA0--