OpenVMS Book Wins award - VMS

This is a discussion on OpenVMS Book Wins award - VMS ; The Minimum You Need to Know About Service Orieted Architecture by Roland Hughes Award-Winner in the Business: Technology/Computers/Internet category of the National Best Books 2008 Awards, sponsored by USA Book News You can find this book in Island Computer's Web ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: OpenVMS Book Wins award

  1. OpenVMS Book Wins award

    The Minimum You Need to Know About Service Orieted Architecture by
    Roland Hughes

    Award-Winner in the Business: Technology/Computers/Internet category
    of the National Best Books 2008 Awards, sponsored by USA Book News

    You can find this book in Island Computer's Web store.

  2. Re: OpenVMS Book Wins award

    Congratulations Roland!!!!!
    Finally...


    --
    David B Turner

    =============================================

    Island Computers US Corp
    PO Box 86
    Tybee GA 31328

    Toll Free: 1-877 636 4332 x201, Mobile x251
    Email: dturner@islandco.com
    International & Local: (001)- 404-806-7749
    Fax: 912 786 8505
    Web: www.islandco.com

    =============================================
    "yyyc186" wrote in message
    news:ee65a5f3-cba1-40a5-829f-59998aa33af5@o4g2000pra.googlegroups.com...
    > The Minimum You Need to Know About Service Orieted Architecture by
    > Roland Hughes
    >
    > Award-Winner in the Business: Technology/Computers/Internet category
    > of the National Best Books 2008 Awards, sponsored by USA Book News
    >
    > You can find this book in Island Computer's Web store.




  3. RE: OpenVMS Book Wins award


    > -----Original Message-----
    > From: yyyc186 [mailto:yyyc186@hughes.net]
    > Sent: Monday, October 20, 2008 1:37 PM
    > To: Info-VAX@Mvb.Saic.Com
    > Subject: OpenVMS Book Wins award
    >
    > The Minimum You Need to Know About Service Orieted Architecture by
    > Roland Hughes
    >
    > Award-Winner in the Business: Technology/Computers/Internet category
    > of the National Best Books 2008 Awards, sponsored by USA Book News
    >
    > You can find this book in Island Computer's Web store.


    Hey, very coooll ..

    :-)

    Additional info:

    http://www.usabooknews.com/bestbooksawards2008.html
    scroll down to:
    Business: Technology/Computers/Internet

    Winner:
    The Minimum You Need to Know About Service Oriented Architecture by Roland Hughes Logikal Solutions

    ISBN 978-0-9770866-6-5

    Some earlier feedback on the book:
    http://www.openvms.org/stories.php?s.../09/27/8565098


    Regards

    Kerry Main
    Senior Consultant
    HP Services Canada
    Voice: 613-254-8911
    Fax: 613-591-4477
    kerryDOTmainAThpDOTcom
    (remove the DOT's and AT)

    OpenVMS - the secure, multi-site OS that just works.





  4. Re: OpenVMS Book Wins award

    On Oct 20, 12:36*pm, yyyc186 wrote:
    > The Minimum You Need to Know About Service Orieted Architecture by
    > Roland Hughes
    >
    > Award-Winner in the Business: Technology/Computers/Internet category
    > of the National Best Books 2008 Awards, sponsored by USA Book News
    >
    > You can find this book in Island Computer's Web store.


    Congratulations, Roland. That is wonderful.

    Rich

  5. Re: OpenVMS Book Wins award

    On 20 Oct, 18:36, yyyc186 wrote:
    > The Minimum You Need to Know About Service Orieted Architecture by
    > Roland Hughes
    >
    > Award-Winner in the Business: Technology/Computers/Internet category
    > of the National Best Books 2008 Awards, sponsored by USA Book News
    >
    > You can find this book in Island Computer's Web store.



    This is the part where the people around here who have not bought one
    of Roland's book rush to island computers web site and buy one.
    ....

  6. Re: OpenVMS Book Wins award

    On Oct 21, 1:59*am, IanMiller wrote:
    > On 20 Oct, 18:36, yyyc186 wrote:
    >
    > > The Minimum You Need to Know About Service Orieted Architecture by
    > > Roland Hughes

    >
    > > Award-Winner in the Business: Technology/Computers/Internet category
    > > of the National Best Books 2008 Awards, sponsored by USA Book News

    >
    > > You can find this book in Island Computer's Web store.

    >
    > This is the part where the people around here who have not bought one
    > of Roland's book rush to island computers web site and buy one.
    > ...


    ROFLMAO

    Somehow I doubt that will happen Ian, but thanks for the thought!

    Roland

  7. Re: OpenVMS Book Wins award

    yyyc186 wrote:
    >
    > The Minimum You Need to Know About Service Orieted Architecture by
    > Roland Hughes
    >
    > Award-Winner in the Business: Technology/Computers/Internet category
    > of the National Best Books 2008 Awards, sponsored by USA Book News
    >
    > You can find this book in Island Computer's Web store.


    Great job, Roland!

    Excellent!

    D.J.D.

  8. Re: OpenVMS Book Wins award

    yyyc186 wrote:
    > The Minimum You Need to Know About Service Orieted Architecture by
    > Roland Hughes
    >
    > Award-Winner in the Business: Technology/Computers/Internet category
    > of the National Best Books 2008 Awards, sponsored by USA Book News


    Congratulations Roland!

    (I purchased it when AU$ was almost at US$ parity :-)

    > You can find this book in Island Computer's Web store.


  9. Banana Republic (was Re: OpenVMS Book Wins award)

    Hi Mark,

    > (I purchased it when AU$ was almost at US$ parity :-)


    Aaah, it seems like only weeks ago :-(

    Cheers Richard Maher

    PS. Just in case you don't subscribe to the WHATWG mailing list, do you have
    any interest in, or opinions on the following: -

    ----- Original Message -----
    From: "Shannon"
    To: "WHAT working group" >
    Sent: Tuesday, October 14, 2008 7:22 AM
    Subject: [whatwg] WebSocket and proxies


    > In the process of testing my WebSocket proposal I discovered the CONNECT
    > method has a major restriction. Most proxies disable CONNECT to anything
    > but port 443.
    >
    > The following is from "Squid and the Blowfish":
    > ------------------
    > It is very important that you stop CONNECT type requests to non-SSL
    > ports. The CONNECT method allows data transfer in any direction at any
    > time, regardless of the transport protocol used. As a consequence, a
    > malicious user could telnet(1) to a (very) badly configured proxy, enter
    > something like:
    > ... snip example ...
    > and end up connected to the remote server, as if the connection was
    > originated by the proxy.
    > -------------------
    >
    > I verified that Squid and all public proxies I tried disable CONNECT by
    > default to non-SSL ports. It's unlikely many internet hosts will have
    > 443 available for WebSockets if they also run a webserver. It could be
    > done with virtual IPs or dedicated hosts but this imposes complex
    > requirements and costs over alternatives like CGI.
    >
    > The availability and capabilities of the OPTIONS and GET protocols also
    > varied from proxy to proxy. The IETF draft related to TLS
    > (http://tools.ietf.org/html/draft-iet...ttp-upgrade-05) has this to

    say:
    >
    > -------------------
    > 3.2 Mandatory Upgrade
    >
    > If an unsecured response would be unacceptable, a client MUST send
    > an OPTIONS request first to complete the switch to TLS/1.0 (if
    > possible).
    >
    > OPTIONS * HTTP/1.1
    > Host: example.bank.com
    > Upgrade: TLS/1.0
    > Connection: Upgrade
    > -------------------
    >
    > So according to this draft spec OPTIONS is the only way to do a
    > *mandatory* upgrade of our connection. Once again this failed in testing
    >
    > -------------------
    > => OPTIONS * HTTP/1.1
    > => Proxy-Connection: keep-alive
    > => Connection: Upgrade
    > => Upgrade: WebSocket/1.0
    > => Host: warriorhut.org:8000
    > =>
    > <= HTTP/1.0 400 Bad Request
    > <= Server: squid/3.0.STABLE8
    > --------------------
    >
    > Other proxies gave different errors or simply returned nothing. The
    > problem may be related to the Upgrade and Connection headers rather than
    > OPTIONS, since I had similar issues using Connection: Upgrade with GET.
    >
    > I had the most success using GET without a Connection: Upgrade header.
    > It seems that the proxy thinks the header is directed at it so it does
    > not pass it on to the remote host. In many cases it will abort the
    > connection. Using the Upgrade: header without Connection allows the
    > Upgrade header through to the actual websocket service.
    >
    > It seems to me that whatever we try in many cases the connection will be
    > silently dropped by the proxy and the reasons will be unclear due to the
    > lack of error handling. There seems to be a wide variation in proxy
    > behaviour for uncommon operations. I suppose proxy developers could fix
    > these issues but whether a significant rollout could be achieved before
    > HTML5 is released is questionable.
    >
    > Given that an asynchronous connection cannot be cached the only reasons
    > remaining for going through a proxy are anonymity and firewall
    > traversal. Automatically bypassing the users proxy configuration to
    > solve the issues above has the potential to break both of these. It
    > would be a significant breach of trust for a UA to bypass the users
    > proxy and some networks only allow connections via a proxy (for security
    > and monitoring).
    >
    > It seems that we're stuck between a rock and hard place here. In light
    > of this I reiterate my earlier suggestion that the time could be better
    > spent providing guidelines for communication via an asynchronous CGI
    > interface. This would allow reuse of existing port 80 and 443 web
    > services which would resolve the cross-domain issues (the CGI can relay
    > the actual service via a backend connection) and most of the proxy
    > issues above (since proxy GET and CONNECT are more reliable on these

    ports).
    >
    > Shannon
    >


    "Mark Daniel" wrote in message
    news:01110d0c$0$20616$c3e8da3@news.astraweb.com...
    > yyyc186 wrote:
    > > The Minimum You Need to Know About Service Orieted Architecture by
    > > Roland Hughes
    > >
    > > Award-Winner in the Business: Technology/Computers/Internet category
    > > of the National Best Books 2008 Awards, sponsored by USA Book News

    >
    > Congratulations Roland!
    >
    > (I purchased it when AU$ was almost at US$ parity :-)
    >
    > > You can find this book in Island Computer's Web store.




  10. Re: Banana Republic (was Re: OpenVMS Book Wins award)

    Richard Maher wrote:
    > Hi Mark,
    >
    >> (I purchased it when AU$ was almost at US$ parity :-)

    >
    > Aaah, it seems like only weeks ago :-(


    I bought it through Barnes and Noble in late May '08 for US$36.00 plus
    US$13.00 P&P, and I think my credit card statement said something like
    AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
    at US$0.65 now escapes me - perhaps that's one reason I'm still working
    for wages.

    It was a good 'background' read but not directly applicable to my
    daytime duty statement these days. I had not (as I indicated to Roland
    I might) gotten around to a public review (that would have required a
    second read). Willem Grooters provided one I'd generally endorse.

    At around the same time I purchased Heller's, "Catch 22" (shipped to one
    of my daughters), Earl's, "Digital Equipment Corporation (MA) (Images
    of America)", and Schein's, "DEC Is Dead, Long Live DEC"; all good
    reads and all for different reasons. With the exchange rate more like
    2:3 I might have to think think more carefully. (The Earl soft-cover is
    a particularly easy but also interesting 'read' I'd recommend to all
    interested in DEC :-)

    > Cheers Richard Maher
    >
    > PS. Just in case you don't subscribe to the WHATWG mailing list, do you have
    > any interest in, or opinions on the following: -


    No I don't and indirectly I guess I do.

    That any network connectivity has some sandboxing doesn't exactly
    surprise me. A network conduit (like SSH or HTTP CONNECT) is carte
    blanche for whatever the agent wishes to transfer. No constraint would
    be considered negligence.

    I'm guessing you mention this because the suggestion below that

    "that the time could be better spent providing guidelines for
    communication via an asynchronous CGI [originally I read GUI :-]
    interface."

    sounds remarkably like Tier3 :-)

    I agree; why would anyone spend time abstracting interfaces if a
    monolithic solution is all that is currently required? Of course this
    is an entirely fresh (if not novel) discussion point ...

    > ----- Original Message -----
    > From: "Shannon"
    > To: "WHAT working group" >
    > Sent: Tuesday, October 14, 2008 7:22 AM
    > Subject: [whatwg] WebSocket and proxies
    >
    >
    >> In the process of testing my WebSocket proposal I discovered the CONNECT
    >> method has a major restriction. Most proxies disable CONNECT to anything
    >> but port 443.
    >>
    >> The following is from "Squid and the Blowfish":
    >> ------------------
    >> It is very important that you stop CONNECT type requests to non-SSL
    >> ports. The CONNECT method allows data transfer in any direction at any
    >> time, regardless of the transport protocol used. As a consequence, a
    >> malicious user could telnet(1) to a (very) badly configured proxy, enter
    >> something like:
    >> ... snip example ...
    >> and end up connected to the remote server, as if the connection was
    >> originated by the proxy.
    >> -------------------
    >>
    >> I verified that Squid and all public proxies I tried disable CONNECT by
    >> default to non-SSL ports. It's unlikely many internet hosts will have
    >> 443 available for WebSockets if they also run a webserver. It could be
    >> done with virtual IPs or dedicated hosts but this imposes complex
    >> requirements and costs over alternatives like CGI.
    >>
    >> The availability and capabilities of the OPTIONS and GET protocols also
    >> varied from proxy to proxy. The IETF draft related to TLS
    >> (http://tools.ietf.org/html/draft-iet...ttp-upgrade-05) has this to

    > say:
    >> -------------------
    >> 3.2 Mandatory Upgrade
    >>
    >> If an unsecured response would be unacceptable, a client MUST send
    >> an OPTIONS request first to complete the switch to TLS/1.0 (if
    >> possible).
    >>
    >> OPTIONS * HTTP/1.1
    >> Host: example.bank.com
    >> Upgrade: TLS/1.0
    >> Connection: Upgrade
    >> -------------------
    >>
    >> So according to this draft spec OPTIONS is the only way to do a
    >> *mandatory* upgrade of our connection. Once again this failed in testing
    >>
    >> -------------------
    >> => OPTIONS * HTTP/1.1
    >> => Proxy-Connection: keep-alive
    >> => Connection: Upgrade
    >> => Upgrade: WebSocket/1.0
    >> => Host: warriorhut.org:8000
    >> =>
    >> <= HTTP/1.0 400 Bad Request
    >> <= Server: squid/3.0.STABLE8
    >> --------------------
    >>
    >> Other proxies gave different errors or simply returned nothing. The
    >> problem may be related to the Upgrade and Connection headers rather than
    >> OPTIONS, since I had similar issues using Connection: Upgrade with GET.
    >>
    >> I had the most success using GET without a Connection: Upgrade header.
    >> It seems that the proxy thinks the header is directed at it so it does
    >> not pass it on to the remote host. In many cases it will abort the
    >> connection. Using the Upgrade: header without Connection allows the
    >> Upgrade header through to the actual websocket service.
    >>
    >> It seems to me that whatever we try in many cases the connection will be
    >> silently dropped by the proxy and the reasons will be unclear due to the
    >> lack of error handling. There seems to be a wide variation in proxy
    >> behaviour for uncommon operations. I suppose proxy developers could fix
    >> these issues but whether a significant rollout could be achieved before
    >> HTML5 is released is questionable.
    >>
    >> Given that an asynchronous connection cannot be cached the only reasons
    >> remaining for going through a proxy are anonymity and firewall
    >> traversal. Automatically bypassing the users proxy configuration to
    >> solve the issues above has the potential to break both of these. It
    >> would be a significant breach of trust for a UA to bypass the users
    >> proxy and some networks only allow connections via a proxy (for security
    >> and monitoring).
    >>
    >> It seems that we're stuck between a rock and hard place here. In light
    >> of this I reiterate my earlier suggestion that the time could be better
    >> spent providing guidelines for communication via an asynchronous CGI
    >> interface. This would allow reuse of existing port 80 and 443 web
    >> services which would resolve the cross-domain issues (the CGI can relay
    >> the actual service via a backend connection) and most of the proxy
    >> issues above (since proxy GET and CONNECT are more reliable on these

    > ports).
    >> Shannon
    >>

    >
    > "Mark Daniel" wrote in message
    > news:01110d0c$0$20616$c3e8da3@news.astraweb.com...
    >> yyyc186 wrote:
    >>> The Minimum You Need to Know About Service Orieted Architecture by
    >>> Roland Hughes
    >>>
    >>> Award-Winner in the Business: Technology/Computers/Internet category
    >>> of the National Best Books 2008 Awards, sponsored by USA Book News

    >> Congratulations Roland!
    >>
    >> (I purchased it when AU$ was almost at US$ parity :-)
    >>
    >>> You can find this book in Island Computer's Web store.


  11. Re: Banana Republic (was Re: OpenVMS Book Wins award)

    Hi Mark,

    Thanks for the reply.

    > I bought it through Barnes and Noble in late May '08 for US$36.00 plus
    > US$13.00 P&P, and I think my credit card statement said something like
    > AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
    > at US$0.65 now escapes me - perhaps that's one reason I'm still working
    > for wages.


    I looked seriously at Perth Mint gold in August (when the bank deposit
    guarantee was sweet FA) and Foreign Currency accounts aren't as common here
    as they are in the UK. Either way I would (and have) lost big time - but
    haven't we all :-(

    > That any network connectivity has some sandboxing doesn't exactly
    > surprise me.


    Me either! I'm a big fan of the same-origin, or codebase, policy for Applets
    but these guys just want to keep pushing the envelope.

    > A network conduit (like SSH or HTTP CONNECT) is carte
    > blanche for whatever the agent wishes to transfer. No constraint would
    > be considered negligence.


    Yeah, but here I bow to your much greater experience and ask "What the hell
    can a *Socket not HTTP* proxy-server do for me?". Look I wanted a HTTP
    CONNECT handshake to give me a Tunnel for my Socket over a httpS connection
    to an arbitray TCP/IP server, but it doesn't look doable; please advise.

    I also view with interest what the Comet guys are doing with Orbited (see
    www.cometdaily.com for some background) as they don't seem to be bound by
    (or have already solved) these proxy-server restrictions.

    > I'm guessing you mention this because the suggestion below that
    >
    > "that the time could be better spent providing guidelines for
    > communication via an asynchronous CGI [originally I read GUI :-]
    > interface."
    >
    > sounds remarkably like Tier3 :-)


    Damn, I'm as transparent and one-domensional as usual :-)

    The way I see it is we have two camps (and I'm happy to live with the
    pluralism and think there's enough room for everyone).

    1) The WebSockets http/html5 guys who have the distinct (and only) advantage
    of being able to tunnel out of 80/443 as HTTP

    2) The New Order of full-blown, connection-oriented, full-duplex, binary,
    Socket Interaction

    If Sockets can't traverse public proxy-servers with existing HTTP then
    option 1 is no longer on the table as far as I can see?

    Anyway, please let me ask the question of why anyone would want to use a
    proxy-server for Socket communication?

    .. Socket Cacheing - No Thanks
    .. Limited client IP addresses - IPV6
    .. Anonymity - Not always a good thing
    .. Firewall - Open up connections to/from valid hosts/ports
    .. Monitoring/filtering - Requirements spec for binary data

    Cheers Richard Maher

    "Mark Daniel" wrote in message
    news:011308d4$0$20645$c3e8da3@news.astraweb.com...
    > Richard Maher wrote:
    > > Hi Mark,
    > >
    > >> (I purchased it when AU$ was almost at US$ parity :-)

    > >
    > > Aaah, it seems like only weeks ago :-(

    >
    > I bought it through Barnes and Noble in late May '08 for US$36.00 plus
    > US$13.00 P&P, and I think my credit card statement said something like
    > AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
    > at US$0.65 now escapes me - perhaps that's one reason I'm still working
    > for wages.
    >
    > It was a good 'background' read but not directly applicable to my
    > daytime duty statement these days. I had not (as I indicated to Roland
    > I might) gotten around to a public review (that would have required a
    > second read). Willem Grooters provided one I'd generally endorse.
    >
    > At around the same time I purchased Heller's, "Catch 22" (shipped to one
    > of my daughters), Earl's, "Digital Equipment Corporation (MA) (Images
    > of America)", and Schein's, "DEC Is Dead, Long Live DEC"; all good
    > reads and all for different reasons. With the exchange rate more like
    > 2:3 I might have to think think more carefully. (The Earl soft-cover is
    > a particularly easy but also interesting 'read' I'd recommend to all
    > interested in DEC :-)
    >
    > > Cheers Richard Maher
    > >
    > > PS. Just in case you don't subscribe to the WHATWG mailing list, do you

    have
    > > any interest in, or opinions on the following: -

    >
    > No I don't and indirectly I guess I do.
    >
    > That any network connectivity has some sandboxing doesn't exactly
    > surprise me. A network conduit (like SSH or HTTP CONNECT) is carte
    > blanche for whatever the agent wishes to transfer. No constraint would
    > be considered negligence.
    >
    > I'm guessing you mention this because the suggestion below that
    >
    > "that the time could be better spent providing guidelines for
    > communication via an asynchronous CGI [originally I read GUI :-]
    > interface."
    >
    > sounds remarkably like Tier3 :-)
    >
    > I agree; why would anyone spend time abstracting interfaces if a
    > monolithic solution is all that is currently required? Of course this
    > is an entirely fresh (if not novel) discussion point ...
    >
    > > ----- Original Message -----
    > > From: "Shannon"
    > > To: "WHAT working group" >
    > > Sent: Tuesday, October 14, 2008 7:22 AM
    > > Subject: [whatwg] WebSocket and proxies
    > >
    > >
    > >> In the process of testing my WebSocket proposal I discovered the

    CONNECT
    > >> method has a major restriction. Most proxies disable CONNECT to

    anything
    > >> but port 443.
    > >>
    > >> The following is from "Squid and the Blowfish":
    > >> ------------------
    > >> It is very important that you stop CONNECT type requests to non-SSL
    > >> ports. The CONNECT method allows data transfer in any direction at any
    > >> time, regardless of the transport protocol used. As a consequence, a
    > >> malicious user could telnet(1) to a (very) badly configured proxy,

    enter
    > >> something like:
    > >> ... snip example ...
    > >> and end up connected to the remote server, as if the connection was
    > >> originated by the proxy.
    > >> -------------------
    > >>
    > >> I verified that Squid and all public proxies I tried disable CONNECT by
    > >> default to non-SSL ports. It's unlikely many internet hosts will have
    > >> 443 available for WebSockets if they also run a webserver. It could be
    > >> done with virtual IPs or dedicated hosts but this imposes complex
    > >> requirements and costs over alternatives like CGI.
    > >>
    > >> The availability and capabilities of the OPTIONS and GET protocols also
    > >> varied from proxy to proxy. The IETF draft related to TLS
    > >> (http://tools.ietf.org/html/draft-iet...ttp-upgrade-05) has this to

    > > say:
    > >> -------------------
    > >> 3.2 Mandatory Upgrade
    > >>
    > >> If an unsecured response would be unacceptable, a client MUST send
    > >> an OPTIONS request first to complete the switch to TLS/1.0 (if
    > >> possible).
    > >>
    > >> OPTIONS * HTTP/1.1
    > >> Host: example.bank.com
    > >> Upgrade: TLS/1.0
    > >> Connection: Upgrade
    > >> -------------------
    > >>
    > >> So according to this draft spec OPTIONS is the only way to do a
    > >> *mandatory* upgrade of our connection. Once again this failed in

    testing
    > >>
    > >> -------------------
    > >> => OPTIONS * HTTP/1.1
    > >> => Proxy-Connection: keep-alive
    > >> => Connection: Upgrade
    > >> => Upgrade: WebSocket/1.0
    > >> => Host: warriorhut.org:8000
    > >> =>
    > >> <= HTTP/1.0 400 Bad Request
    > >> <= Server: squid/3.0.STABLE8
    > >> --------------------
    > >>
    > >> Other proxies gave different errors or simply returned nothing. The
    > >> problem may be related to the Upgrade and Connection headers rather

    than
    > >> OPTIONS, since I had similar issues using Connection: Upgrade with GET.
    > >>
    > >> I had the most success using GET without a Connection: Upgrade header.
    > >> It seems that the proxy thinks the header is directed at it so it does
    > >> not pass it on to the remote host. In many cases it will abort the
    > >> connection. Using the Upgrade: header without Connection allows the
    > >> Upgrade header through to the actual websocket service.
    > >>
    > >> It seems to me that whatever we try in many cases the connection will

    be
    > >> silently dropped by the proxy and the reasons will be unclear due to

    the
    > >> lack of error handling. There seems to be a wide variation in proxy
    > >> behaviour for uncommon operations. I suppose proxy developers could fix
    > >> these issues but whether a significant rollout could be achieved before
    > >> HTML5 is released is questionable.
    > >>
    > >> Given that an asynchronous connection cannot be cached the only reasons
    > >> remaining for going through a proxy are anonymity and firewall
    > >> traversal. Automatically bypassing the users proxy configuration to
    > >> solve the issues above has the potential to break both of these. It
    > >> would be a significant breach of trust for a UA to bypass the users
    > >> proxy and some networks only allow connections via a proxy (for

    security
    > >> and monitoring).
    > >>
    > >> It seems that we're stuck between a rock and hard place here. In light
    > >> of this I reiterate my earlier suggestion that the time could be better
    > >> spent providing guidelines for communication via an asynchronous CGI
    > >> interface. This would allow reuse of existing port 80 and 443 web
    > >> services which would resolve the cross-domain issues (the CGI can relay
    > >> the actual service via a backend connection) and most of the proxy
    > >> issues above (since proxy GET and CONNECT are more reliable on these

    > > ports).
    > >> Shannon
    > >>

    > >
    > > "Mark Daniel" wrote in message
    > > news:01110d0c$0$20616$c3e8da3@news.astraweb.com...
    > >> yyyc186 wrote:
    > >>> The Minimum You Need to Know About Service Orieted Architecture by
    > >>> Roland Hughes
    > >>>
    > >>> Award-Winner in the Business: Technology/Computers/Internet category
    > >>> of the National Best Books 2008 Awards, sponsored by USA Book News
    > >> Congratulations Roland!
    > >>
    > >> (I purchased it when AU$ was almost at US$ parity :-)
    > >>
    > >>> You can find this book in Island Computer's Web store.




  12. Re: Banana Republic (was Re: OpenVMS Book Wins award)

    Richard Maher wrote:
    > Hi Mark,
    >
    > Thanks for the reply.
    >
    >> I bought it through Barnes and Noble in late May '08 for US$36.00 plus
    >> US$13.00 P&P, and I think my credit card statement said something like
    >> AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
    >> at US$0.65 now escapes me - perhaps that's one reason I'm still working
    >> for wages.

    >
    > I looked seriously at Perth Mint gold in August (when the bank deposit
    > guarantee was sweet FA) and Foreign Currency accounts aren't as common here
    > as they are in the UK. Either way I would (and have) lost big time - but
    > haven't we all :-(
    >
    >> That any network connectivity has some sandboxing doesn't exactly
    >> surprise me.

    >
    > Me either! I'm a big fan of the same-origin, or codebase, policy for Applets
    > but these guys just want to keep pushing the envelope.


    I noted the post on Adobe policy files.

    >> A network conduit (like SSH or HTTP CONNECT) is carte
    >> blanche for whatever the agent wishes to transfer. No constraint would
    >> be considered negligence.

    >
    > Yeah, but here I bow


    ;-)

    > to your much greater experience and ask "What the hell
    > can a *Socket not HTTP* proxy-server do for me?".


    Isn't a(n IP) socket proxy that doesn't explicitly talk HTTP during
    setup a one-to-one NAT router? And if accepting external connection
    requests, a static port mapping NAT router, into/through the DMZ and
    onto internal services? And so forth through the NAT variants.

    > Look I wanted a HTTP
    > CONNECT handshake to give me a Tunnel for my Socket over a httpS connection
    > to an arbitray TCP/IP server, but it doesn't look doable; please advise.


    I can but reframe my previous comment; unconstrained connectivity from
    browser based applications is surely like signing a full book of blank
    cheques.

    > I also view with interest what the Comet guys are doing with Orbited (see
    > www.cometdaily.com for some background) as they don't seem to be bound by
    > (or have already solved) these proxy-server restrictions.


    AIUI; Orbited is a service used to accept Web-style socket connection
    requests from browsers, establish Comet-style, bidirectional
    communication with the browser, then proxy (or forward, or gateway, or
    ) that communication via
    a TCP socket to the requested end-point. Without some sort of access
    control it functions as an open relay - carte blanche. With access
    control it's a lot like most CONNECT proxy, or at least CONNECT
    reverse-proxy. Of course it's a bit more than that (but isn't
    everything!) Until Web Sockets become commonplace it uses a number of
    approaches to *emulate* asynchronous comms with current browsers.

    AIUI; Comet is a broad term used to described leveraging HTTP
    server-push of unsolicited/unpolled/asynchronous data to the browser,
    using existing HTTP technologies, most commonly, though not restricted
    to, streaming of a series individual response data 'inside' a persisting
    HTTP connection, currently via 'long polling' and XMLhttpRequest() or