From cliff at pinestream.com  Thu Feb 14 10:35:46 2008
From: cliff at pinestream.com (Cliff Hirsch)
Date: Thu, 14 Feb 2008 10:35:46 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
Message-ID: <C3D9CA02.CBB7%cliff@pinestream.com>

Is anyone running a Linux VM under OSX using Parallels?

Any suggestions? I would like to find one that mirrors my rhel enterprise
server 4 environment as closely as possible.

Cliff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/bostonphptalk/attachments/20080214/d9101dfe/attachment.htm>

From johnston.joshua at gmail.com  Thu Feb 14 10:40:01 2008
From: johnston.joshua at gmail.com (Joshua Johnston)
Date: Thu, 14 Feb 2008 10:40:01 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <C3D9CA02.CBB7%cliff@pinestream.com>
References: <C3D9CA02.CBB7%cliff@pinestream.com>
Message-ID: <7AB2431E-691B-4B1B-A3E5-5D544417B553@gmail.com>

Cliff,

I have not personally but a co-worker of mine had OpenSuSE 10.2  
running in Parallels 3 on OS X 10.4. If I remember when I get home  
tonight I am going to load it up on my OS X 10.5.2 w/Parallels 2.

The co-worker said it worked just fine.

Josh

On Feb 14, 2008, at 10:35 AM, Cliff Hirsch wrote:

> Is anyone running a Linux VM under OSX using Parallels?
>
> Any suggestions? I would like to find one that mirrors my rhel  
> enterprise server 4 environment as closely as possible.
>
> Cliff
> _______________________________________________
> Bostonphptalk mailing list
> Bostonphptalk at bostonphp.org
> http://seven.pairlist.net/mailman/listinfo/bostonphptalk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/bostonphptalk/attachments/20080214/e63f34e7/attachment.htm>

From cliff at pinestream.com  Thu Feb 14 10:46:52 2008
From: cliff at pinestream.com (Cliff Hirsch)
Date: Thu, 14 Feb 2008 10:46:52 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <7AB2431E-691B-4B1B-A3E5-5D544417B553@gmail.com>
Message-ID: <C3D9CC9C.CBBD%cliff@pinestream.com>

Thanks. Will check it out. But from my brief foray with SuSE, I think the
Novell distro is just different enough from the Redhat distro to be
frustrating for me.

On 2/14/08 10:40 AM, "Joshua Johnston" <johnston.joshua at gmail.com> wrote:

> Cliff,
> 
> I have not personally but a co-worker of mine had OpenSuSE 10.2 running in
> Parallels 3 on OS X 10.4. If I remember when I get home tonight I am going to
> load it up on my OS X 10.5.2 w/Parallels 2.
> 
> The co-worker said it worked just fine.
> 
> Josh
> 
> On Feb 14, 2008, at 10:35 AM, Cliff Hirsch wrote:
> 
>>  Is anyone running a Linux VM under OSX using Parallels?
>>  
>>  Any suggestions? I would like to find one that mirrors my rhel enterprise
>> server 4 environment as closely as possible.
>>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/bostonphptalk/attachments/20080214/59f060cc/attachment.htm>

From bob at rsi.com  Thu Feb 14 11:07:14 2008
From: bob at rsi.com (Bob Gorman)
Date: Thu, 14 Feb 2008 11:07:14 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <C3D9CA02.CBB7%cliff@pinestream.com>
References: <C3D9CA02.CBB7%cliff@pinestream.com>
Message-ID: <47B46732.5020902@rsi.com>

On 02/14/2008 10:35 AM, Cliff Hirsch wrote:
> Is anyone running a Linux VM under OSX using Parallels?
> 
> Any suggestions? I would like to find one that mirrors my rhel 
> enterprise server 4 environment as closely as possible.

A sideways answer...

VMware Fusion will run RHEL.

http://www.vmware.com/products/fusion/

Free trial, cheap to buy.


From cliff at pinestream.com  Thu Feb 14 15:14:23 2008
From: cliff at pinestream.com (Cliff Hirsch)
Date: Thu, 14 Feb 2008 15:14:23 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <47B46732.5020902@rsi.com>
Message-ID: <C3DA0B4F.CBFC%cliff@pinestream.com>

On 2/14/08 11:07 AM, "Bob Gorman" <bob at rsi.com> wrote:

> On 02/14/2008 10:35 AM, Cliff Hirsch wrote:
>> Is anyone running a Linux VM under OSX using Parallels?
>> 
>> Any suggestions? I would like to find one that mirrors my rhel
>> enterprise server 4 environment as closely as possible.
> 
> A sideways answer...
> 
> VMware Fusion will run RHEL.
> 
> http://www.vmware.com/products/fusion/
> 
> Free trial, cheap to buy.

Ugh, another vm...already purchased Parallels.

Found this: 
http://www.parallels.com/en/ptn/dir/?psize=8&page=3&categ=&sort=rating&lsort
=

What is most rhel-like? Ubunto, Gentoo, Debian, or CentOS.

CentOS -- right?



From tboyden at supercoups.com  Thu Feb 14 16:35:23 2008
From: tboyden at supercoups.com (Timothy Boyden)
Date: Thu, 14 Feb 2008 16:35:23 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <C3D9CA02.CBB7%cliff@pinestream.com>
References: <C3D9CA02.CBB7%cliff@pinestream.com>
Message-ID: <C12F0900C695FF47AEE0A7C2C75760A001031E78@greenmonster.supercoups.local>

Cliff,
 
I'm running Fedora 8 in Parallels on my Macbook. I also run Ubuntu
(which I find easier to use) and Windows XP virtual machines. Anything
in particular your looking for?
 
-Tim
 
---------------------------
Timothy Boyden
Network Administrator
tboyden at supercoups.com <mailto:tboyden at supercoups.com> 
SuperCoups(r) 

A Valassis Company

350 Revolutionary Drive | E. Taunton, MA 02718

Phone: 508-977-2034  | Fax: 508-977-0290  |  www.supercoups.com
<http://www.supercoups.com/>  

 

Watch For Your Bright Blue and Yellow Envelope - Coming Soon!

---------------------------


RedPlum <http://www.redplum.com/>  is the ultimate source of value -
online, in your mailbox, on your doorstep, with your newspaper, and in
your store.

 

This message may include proprietary or protected information. If you
are not the intended recipient, please notify me, delete this message
and do not further communicate the information contained herein without
my express consent.

 

________________________________

From: bostonphptalk-bounces at bostonphp.org
[mailto:bostonphptalk-bounces at bostonphp.org] On Behalf Of Cliff Hirsch
Sent: Thursday, February 14, 2008 10:36 AM
To: bostonphptalk at bostonphp.org
Subject: [Bostonphptalk] Linux VM for OSX suggestions


Is anyone running a Linux VM under OSX using Parallels?

Any suggestions? I would like to find one that mirrors my rhel
enterprise server 4 environment as closely as possible.

Cliff 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/bostonphptalk/attachments/20080214/36ae3e98/attachment.htm>

From johnston.joshua at gmail.com  Thu Feb 14 17:00:45 2008
From: johnston.joshua at gmail.com (Joshua Johnston)
Date: Thu, 14 Feb 2008 17:00:45 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <C3DA0B4F.CBFC%cliff@pinestream.com>
References: <C3DA0B4F.CBFC%cliff@pinestream.com>
Message-ID: <1F7EDA68-B2F6-4846-AC02-656570B417D7@gmail.com>

On Feb 14, 2008, at 3:14 PM, Cliff Hirsch wrote:

> On 2/14/08 11:07 AM, "Bob Gorman" <bob at rsi.com> wrote:
>
>> On 02/14/2008 10:35 AM, Cliff Hirsch wrote:
>>> Is anyone running a Linux VM under OSX using Parallels?
>>>
>>> Any suggestions? I would like to find one that mirrors my rhel
>>> enterprise server 4 environment as closely as possible.
>>
>> A sideways answer...
>>
>> VMware Fusion will run RHEL.
>>
>> http://www.vmware.com/products/fusion/
>>
>> Free trial, cheap to buy.
>
> Ugh, another vm...already purchased Parallels.
>
> Found this:
> http://www.parallels.com/en/ptn/dir/?psize=8&page=3&categ=&sort=rating&lsort
> =
>
> What is most rhel-like? Ubunto, Gentoo, Debian, or CentOS.
>
> CentOS -- right?
>


Can't you just install RH into your own Parallels VM?


From bob at rsi.com  Thu Feb 14 21:11:23 2008
From: bob at rsi.com (Bob Gorman)
Date: Thu, 14 Feb 2008 21:11:23 -0500
Subject: [Bostonphptalk] Linux VM for OSX suggestions
In-Reply-To: <C3DA0B4F.CBFC%cliff@pinestream.com>
References: <C3DA0B4F.CBFC%cliff@pinestream.com>
Message-ID: <47B4F4CB.6020604@rsi.com>

On 02/14/2008 03:14 PM, Cliff Hirsch wrote:
> What is most rhel-like? Ubunto, Gentoo, Debian, or CentOS.

CentOS is rebranded RHEL.
Fedora is development for RHEL.

If you run either in a VM, don't load a xen kernel.


From cliff at pinestream.com  Mon Feb 25 15:23:02 2008
From: cliff at pinestream.com (Cliff Hirsch)
Date: Mon, 25 Feb 2008 15:23:02 -0500
Subject: [Bostonphptalk] SEO friendly URLs
Message-ID: <C3E88DD6.D13E%cliff@pinestream.com>

Just a warning to anyone considering SEO friendly URLs. Be careful...

SEO friendly URLs look wicked cool, but the road is fraught with peril. If
you are working within the context of a Framework that supports them, you
will probably be ok ? I?m guessing. But watch/think about everything.
Css/js/image paths, ajax, urls in places you may not expect, js query string
manipulation, position, legacy versus new friendly url support, blah, blah,
blah. There?s more to it than meets the eye.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/bostonphptalk/attachments/20080225/794443bd/attachment.htm>

From denonymous at coldcircuit.net  Mon Feb 25 16:18:17 2008
From: denonymous at coldcircuit.net (Mike Johnson)
Date: Mon, 25 Feb 2008 16:18:17 -0500
Subject: [Bostonphptalk] SEO friendly URLs
In-Reply-To: <C3E88DD6.D13E%cliff@pinestream.com>
References: <C3E88DD6.D13E%cliff@pinestream.com>
Message-ID: <47C33099.6090103@coldcircuit.net>

On 2/25/2008 3:23 PM Cliff Hirsch said:

> Just a warning to anyone considering SEO friendly URLs. Be 
 > careful...
> 
> SEO friendly URLs look wicked cool, but the road is fraught with 
 > peril. If you are working within the context of a Framework that
 > supports them, you will probably be ok ? I?m guessing. But
 > watch/think about everything. Css/js/image paths, ajax, urls in
 > places you may not expect, js query string manipulation,
 > position, legacy versus new friendly url support, blah, blah,
 > blah. There?s more to it than meets the eye.

Could you be more specific about some of the things you've run into? I 
do quite a bit of SEO-friendly URL rewriting at work and I'm curious 
about some of what you're mentioning -- specifically css/js/image paths, 
ajax, js query string manipulation, and position.

I've seen my share of URLs in places you may not expect -- the "oh yeah, 
I guess that /is/ possible now that I think of it" discovery -- as well 
as legacy vs new support, doing tricks with 301s and hoping you never 
hit an infinite redirect loop in doing so (though at least Firefox 
recognizes that and stops after 10 or so redirects).

Anyway, anything you can share would be cool. I may be able to lend some 
tips from things I've run into, or maybe vice-versa.

-- 
Mike Johnson


From cliff at pinestream.com  Mon Feb 25 17:42:02 2008
From: cliff at pinestream.com (Cliff Hirsch)
Date: Mon, 25 Feb 2008 17:42:02 -0500
Subject: [Bostonphptalk] SEO friendly URLs
In-Reply-To: <47C33099.6090103@coldcircuit.net>
Message-ID: <C3E8AE6A.D15A%cliff@pinestream.com>

> On 2/25/2008 3:23 PM Cliff Hirsch said:
> 
>> Just a warning to anyone considering SEO friendly URLs. Be
>> careful...
>> 
> Could you be more specific about some of the things you've run into? I

Sure, for starters:

1. All content will need to be relative to root. No more href="content".
CSS, Javascript, images files will need to be href="/content"

2. Those "lurking" scripts will also need to be relative to root. Do you
really have a single point of entry? Perhaps there are a few other
scripts... If so, make sure they are relative to root.

3. Watch for content links embedded in your CSS and Javascript. This will
naturally include your static javascript files and dynamically generated js.

4. If you have controllers that can be be accessed by different
"front-ends", be careful. A link like "/?" may be ok for the default
front-end, but it will mess up if you have a "secondary" front-end. Instead
of the script you want, it will link to the default front-end controller.

5. Watch your param order. Say you have an embedded widget that checks for a
category id, regardless of other content on the page. With ?category_id=#,
things are simple. But if you are expecting it in a specific order in the
url, make sure you don't have conflicts with other controllers and
understand what happens when it is absent.

These are most of them. Really just annoying path info stuff -- not rocket
science, but just a warning because the change from query string to pretty
url affects more than meets the eye. Depending on your code, lot's of
"stuff" will need to be cleaned up.

In the end you will have prettier links and cleaner code though.



From aridavidow at gmail.com  Mon Feb 25 17:54:59 2008
From: aridavidow at gmail.com (Ari Davidow)
Date: Mon, 25 Feb 2008 17:54:59 -0500
Subject: [Bostonphptalk] SEO friendly URLs
In-Reply-To: <C3E8AE6A.D15A%cliff@pinestream.com>
References: <47C33099.6090103@coldcircuit.net>
	<C3E8AE6A.D15A%cliff@pinestream.com>
Message-ID: <747cfaf50802251454w6131457arc4b695bab44e1bd0@mail.gmail.com>

Here's the thing. You can either set yourself up for what we are calling
"SEO-friendly" URLs, or each and every time you migrate to a new system or
revamp the old one, every damn URL will change, thoroughly messing up
bookmarks, and possibly your internals. That is thoroughly and inesculpably
amateur and deserves the poor SEO ranking it draws.

There are many ways to ensure that you never have URLs of the ilk
...?f=793&y=26

Find one that works with your framework or your code and do it, if any of
this (bookmarkability, SEO, etc.) matters to you.

ari

On Mon, Feb 25, 2008 at 5:42 PM, Cliff Hirsch <cliff at pinestream.com> wrote:

> > On 2/25/2008 3:23 PM Cliff Hirsch said:
> >
> >> Just a warning to anyone considering SEO friendly URLs. Be
> >> careful...
> >>
> > Could you be more specific about some of the things you've run into? I
>
> Sure, for starters:
>
> 1. All content will need to be relative to root. No more href="content".
> CSS, Javascript, images files will need to be href="/content"
>
> 2. Those "lurking" scripts will also need to be relative to root. Do you
> really have a single point of entry? Perhaps there are a few other
> scripts... If so, make sure they are relative to root.
>
> 3. Watch for content links embedded in your CSS and Javascript. This will
> naturally include your static javascript files and dynamically generated
> js.
>
> 4. If you have controllers that can be be accessed by different
> "front-ends", be careful. A link like "/?" may be ok for the default
> front-end, but it will mess up if you have a "secondary" front-end.
> Instead
> of the script you want, it will link to the default front-end controller.
>
> 5. Watch your param order. Say you have an embedded widget that checks for
> a
> category id, regardless of other content on the page. With ?category_id=#,
> things are simple. But if you are expecting it in a specific order in the
> url, make sure you don't have conflicts with other controllers and
> understand what happens when it is absent.
>
> These are most of them. Really just annoying path info stuff -- not rocket
> science, but just a warning because the change from query string to pretty
> url affects more than meets the eye. Depending on your code, lot's of
> "stuff" will need to be cleaned up.
>
> In the end you will have prettier links and cleaner code though.
>
>
> _______________________________________________
> Bostonphptalk mailing list
> Bostonphptalk at bostonphp.org
> http://seven.pairlist.net/mailman/listinfo/bostonphptalk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://seven.pairlist.net/pipermail/bostonphptalk/attachments/20080225/8476b781/attachment.htm>

From ken at secdat.com  Fri Feb 29 09:10:36 2008
From: ken at secdat.com (Kenneth Downs)
Date: Fri, 29 Feb 2008 09:10:36 -0500
Subject: [Bostonphptalk] Eliminating the "A" in AJAX
Message-ID: <47C8125C.5010102@secdat.com>

Having AJAX be asynchronous is horrible.  I hate it.  It breaks all of 
the most elementary structure in programming.

It so happens you can eliminate the "A" from Ajax, using an approach 
most of us would not think of because the code police will yell at you 
for it, but here it is:

function syncHTTP(getString) {
    // set up the call
    var http = browserCompatibleMakeRequestObject();
    http.open('get', getString);
    http.onreadystatechange = this.obligatoryHandler
    http.send(null);
       
     // Here is the basic heresy.  We go into a loop
     // with no way to prevent burning CPU cycles.  The
     // obvious assumption here is that the call will succeed
      while(http.readyState != 4) {
            // Gosh, I sure wish Javascript had some kind of
            // Sleep() function, I would do sleep(100) here
      }

    // A really great function that does not exist would be:
    try {
        wait until(http.readyState==4) timeout 5000;
    {
    catch (e) {
       alert("The server never responded!")
    }

     // Now we are out of the loop, it must have returned
     alert(http.responseText);
}

function obligatoryHandler() { /* do nothing */ }


The basic unthinkable act is that endless loop waiting for the 
response.  We are told not to do this for a variety of reasons, most of 
which make no sense in this context. 

One of the reasons we would not do this is because if the server call 
fails we get a hanging system.  But of course if the server call fails 
we probably have big problems anyway, so a timeout after 5 seconds and a 
graceful failure would be a necessary addition anyway.

Another reason we would not do this is because it would burn cycles, but 
I think this is bunk in some situations.  In Google Maps the 
asynchronous may be vital, but in regular database applications we 
assume the user cannot proceed without the results of the call, and is 
sitting there waiting anyway.

So those are just some thoughts, now its back to real work....

-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010


From tboyden at supercoups.com  Fri Feb 29 09:32:22 2008
From: tboyden at supercoups.com (Timothy Boyden)
Date: Fri, 29 Feb 2008 09:32:22 -0500
Subject: [Bostonphptalk] Eliminating the "A" in AJAX
In-Reply-To: <47C8125C.5010102@secdat.com>
References: <47C8125C.5010102@secdat.com>
Message-ID: <C12F0900C695FF47AEE0A7C2C75760A0010A21AD@greenmonster.supercoups.local>

Ken,

If you don't like the asynchronous part:

change: request.open("GET or POST", url, true);

to: request.open("GET or POST", url, false);

Problem solved.

But then that kind of defeats the point of using AJAX in the first
place...

Best book I've read on the subject is Head Rush AJAX from O'Reilly.
Breaks the concepts down and points out all of the gotchas.

Cheers,

Tim


 

-----Original Message-----
From: bostonphptalk-bounces at bostonphp.org
[mailto:bostonphptalk-bounces at bostonphp.org] On Behalf Of Kenneth Downs
Sent: Friday, February 29, 2008 9:11 AM
To: bostonphptalk at bostonphp.org
Subject: [Bostonphptalk] Eliminating the "A" in AJAX

Having AJAX be asynchronous is horrible.  I hate it.  It breaks all of
the most elementary structure in programming.

It so happens you can eliminate the "A" from Ajax, using an approach
most of us would not think of because the code police will yell at you
for it, but here it is:

function syncHTTP(getString) {
    // set up the call
    var http = browserCompatibleMakeRequestObject();
    http.open('get', getString);
    http.onreadystatechange = this.obligatoryHandler
    http.send(null);
       
     // Here is the basic heresy.  We go into a loop
     // with no way to prevent burning CPU cycles.  The
     // obvious assumption here is that the call will succeed
      while(http.readyState != 4) {
            // Gosh, I sure wish Javascript had some kind of
            // Sleep() function, I would do sleep(100) here
      }

    // A really great function that does not exist would be:
    try {
        wait until(http.readyState==4) timeout 5000;
    {
    catch (e) {
       alert("The server never responded!")
    }

     // Now we are out of the loop, it must have returned
     alert(http.responseText);
}

function obligatoryHandler() { /* do nothing */ }


The basic unthinkable act is that endless loop waiting for the response.
We are told not to do this for a variety of reasons, most of which make
no sense in this context. 

One of the reasons we would not do this is because if the server call
fails we get a hanging system.  But of course if the server call fails
we probably have big problems anyway, so a timeout after 5 seconds and a
graceful failure would be a necessary addition anyway.

Another reason we would not do this is because it would burn cycles, but
I think this is bunk in some situations.  In Google Maps the
asynchronous may be vital, but in regular database applications we
assume the user cannot proceed without the results of the call, and is
sitting there waiting anyway.

So those are just some thoughts, now its back to real work....

--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010

_______________________________________________
Bostonphptalk mailing list
Bostonphptalk at bostonphp.org
http://seven.pairlist.net/mailman/listinfo/bostonphptalk

From tboyden at supercoups.com  Fri Feb 29 09:46:06 2008
From: tboyden at supercoups.com (Timothy Boyden)
Date: Fri, 29 Feb 2008 09:46:06 -0500
Subject: [Bostonphptalk] Eliminating the "A" in AJAX
In-Reply-To: <C12F0900C695FF47AEE0A7C2C75760A0010A21AD@greenmonster.supercoups.local>
References: <47C8125C.5010102@secdat.com>
	<C12F0900C695FF47AEE0A7C2C75760A0010A21AD@greenmonster.supercoups.local>
Message-ID: <C12F0900C695FF47AEE0A7C2C75760A0010A21B0@greenmonster.supercoups.local>

Whoops, sorry forgot to add my request function code...

/* AJAX.JS */

var request = null;

try {
	request = new XMLHttpRequest();
} catch (trymicrosoft) {
	try {
		request = new ActiveXObject{"Msxml2.XMLHTTP");
	} catch (othermicrosoft) {
		try {
			request = new
ActiveXObject("Microsoft.XMLHTTP");
		} catch (failed) {
			request = null;
		}
	}
}
if (request == null)
	alert("Error creating request object!");


Cheers,

Tim

 

-----Original Message-----
From: bostonphptalk-bounces at bostonphp.org
[mailto:bostonphptalk-bounces at bostonphp.org] On Behalf Of Timothy Boyden
Sent: Friday, February 29, 2008 9:32 AM
To: bostonphptalk at bostonphp.org
Subject: Re: [Bostonphptalk] Eliminating the "A" in AJAX

Ken,

If you don't like the asynchronous part:

change: request.open("GET or POST", url, true);

to: request.open("GET or POST", url, false);

Problem solved.

But then that kind of defeats the point of using AJAX in the first
place...

Best book I've read on the subject is Head Rush AJAX from O'Reilly.
Breaks the concepts down and points out all of the gotchas.

Cheers,

Tim


 

-----Original Message-----
From: bostonphptalk-bounces at bostonphp.org
[mailto:bostonphptalk-bounces at bostonphp.org] On Behalf Of Kenneth Downs
Sent: Friday, February 29, 2008 9:11 AM
To: bostonphptalk at bostonphp.org
Subject: [Bostonphptalk] Eliminating the "A" in AJAX

Having AJAX be asynchronous is horrible.  I hate it.  It breaks all of
the most elementary structure in programming.

It so happens you can eliminate the "A" from Ajax, using an approach
most of us would not think of because the code police will yell at you
for it, but here it is:

function syncHTTP(getString) {
    // set up the call
    var http = browserCompatibleMakeRequestObject();
    http.open('get', getString);
    http.onreadystatechange = this.obligatoryHandler
    http.send(null);
       
     // Here is the basic heresy.  We go into a loop
     // with no way to prevent burning CPU cycles.  The
     // obvious assumption here is that the call will succeed
      while(http.readyState != 4) {
            // Gosh, I sure wish Javascript had some kind of
            // Sleep() function, I would do sleep(100) here
      }

    // A really great function that does not exist would be:
    try {
        wait until(http.readyState==4) timeout 5000;
    {
    catch (e) {
       alert("The server never responded!")
    }

     // Now we are out of the loop, it must have returned
     alert(http.responseText);
}

function obligatoryHandler() { /* do nothing */ }


The basic unthinkable act is that endless loop waiting for the response.
We are told not to do this for a variety of reasons, most of which make
no sense in this context. 

One of the reasons we would not do this is because if the server call
fails we get a hanging system.  But of course if the server call fails
we probably have big problems anyway, so a timeout after 5 seconds and a
graceful failure would be a necessary addition anyway.

Another reason we would not do this is because it would burn cycles, but
I think this is bunk in some situations.  In Google Maps the
asynchronous may be vital, but in regular database applications we
assume the user cannot proceed without the results of the call, and is
sitting there waiting anyway.

So those are just some thoughts, now its back to real work....

--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010

_______________________________________________
Bostonphptalk mailing list
Bostonphptalk at bostonphp.org
http://seven.pairlist.net/mailman/listinfo/bostonphptalk
_______________________________________________
Bostonphptalk mailing list
Bostonphptalk at bostonphp.org
http://seven.pairlist.net/mailman/listinfo/bostonphptalk

From ken at secdat.com  Fri Feb 29 09:48:52 2008
From: ken at secdat.com (Kenneth Downs)
Date: Fri, 29 Feb 2008 09:48:52 -0500
Subject: [Bostonphptalk] Eliminating the "A" in AJAX
In-Reply-To: <C12F0900C695FF47AEE0A7C2C75760A0010A21AD@greenmonster.supercoups.local>
References: <47C8125C.5010102@secdat.com>
	<C12F0900C695FF47AEE0A7C2C75760A0010A21AD@greenmonster.supercoups.local>
Message-ID: <47C81B54.80600@secdat.com>

Timothy Boyden wrote:
> Ken,
>
> If you don't like the asynchronous part:
>
> change: request.open("GET or POST", url, true);
>
> to: request.open("GET or POST", url, false);
>
> Problem solved.
>   

Thanks!  I'm very glad I made the post, now it's much simpler.

> But then that kind of defeats the point of using AJAX in the first
> place...
>   
The existence of the option implies two classes of needs.  When you are 
coding desktop-in-a-browser type stuff you really have a different set 
of needs than google maps

> Best book I've read on the subject is Head Rush AJAX from O'Reilly.
> Breaks the concepts down and points out all of the gotchas.
>
> Cheers,
>
> Tim
>
>
>  
>
> -----Original Message-----
> From: bostonphptalk-bounces at bostonphp.org
> [mailto:bostonphptalk-bounces at bostonphp.org] On Behalf Of Kenneth Downs
> Sent: Friday, February 29, 2008 9:11 AM
> To: bostonphptalk at bostonphp.org
> Subject: [Bostonphptalk] Eliminating the "A" in AJAX
>
> Having AJAX be asynchronous is horrible.  I hate it.  It breaks all of
> the most elementary structure in programming.
>
> It so happens you can eliminate the "A" from Ajax, using an approach
> most of us would not think of because the code police will yell at you
> for it, but here it is:
>
> function syncHTTP(getString) {
>     // set up the call
>     var http = browserCompatibleMakeRequestObject();
>     http.open('get', getString);
>     http.onreadystatechange = this.obligatoryHandler
>     http.send(null);
>        
>      // Here is the basic heresy.  We go into a loop
>      // with no way to prevent burning CPU cycles.  The
>      // obvious assumption here is that the call will succeed
>       while(http.readyState != 4) {
>             // Gosh, I sure wish Javascript had some kind of
>             // Sleep() function, I would do sleep(100) here
>       }
>
>     // A really great function that does not exist would be:
>     try {
>         wait until(http.readyState==4) timeout 5000;
>     {
>     catch (e) {
>        alert("The server never responded!")
>     }
>
>      // Now we are out of the loop, it must have returned
>      alert(http.responseText);
> }
>
> function obligatoryHandler() { /* do nothing */ }
>
>
> The basic unthinkable act is that endless loop waiting for the response.
> We are told not to do this for a variety of reasons, most of which make
> no sense in this context. 
>
> One of the reasons we would not do this is because if the server call
> fails we get a hanging system.  But of course if the server call fails
> we probably have big problems anyway, so a timeout after 5 seconds and a
> graceful failure would be a necessary addition anyway.
>
> Another reason we would not do this is because it would burn cycles, but
> I think this is bunk in some situations.  In Google Maps the
> asynchronous may be vital, but in regular database applications we
> assume the user cannot proceed without the results of the call, and is
> sitting there waiting anyway.
>
> So those are just some thoughts, now its back to real work....
>
> --
> Kenneth Downs
> Secure Data Software, Inc.
> www.secdat.com    www.andromeda-project.org
> 631-689-7200   Fax: 631-689-0527
> cell: 631-379-0010
>
> _______________________________________________
> Bostonphptalk mailing list
> Bostonphptalk at bostonphp.org
> http://seven.pairlist.net/mailman/listinfo/bostonphptalk
> _______________________________________________
> Bostonphptalk mailing list
> Bostonphptalk at bostonphp.org
> http://seven.pairlist.net/mailman/listinfo/bostonphptalk
>   


-- 
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com    www.andromeda-project.org
631-689-7200   Fax: 631-689-0527
cell: 631-379-0010