AJAX for artists

<xmp>
Intro to Ajax-XMLRPC. (I promised this a year ago…, but you know stuff happens) I think this will enable a good deal of new art work so here goes nuthin…

For many applications, developing a server side client to act as a go between is sometimes overkill.
JavaScript supports XML transport and XML parsing.
The Msxml2.XMLHTTP object has support in IE and Mozilla, (See below for a cross browser hack ).
The advantage here is that the processing is done by the client and the server just has to echo XML documents. XMLRPC is a great candidate, and the programming model is pretty simple. A new technology, Ajax, is based on this type of asynchronous callback.
The clean client below demonstrates a communication to the server, and the return processing by the client. As long as the processing program resides on the same server as the client document, any security checks will be bypassed.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>A clean client</title>
</head>
<body>
<script>
xmldoc = new ActiveXObject("Msxml2.DOMDocument");
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
xmlhttp.Open("Get","http://munro.humber.ca/~dymond/webservice/area/xml_rpc.php",false);
xmlhttp.send();
xmldoc.loadXML(xmlhttp.responseText); //load the returned stream into the dom document
alert(xmldoc.xml)
alert(xmldoc.text)
alert(xmldoc.getElementsByTagName("int").item(1).text)
</script>
</body>
</html>

The combination of the DOM and the XMLHTTP object prove pretty powerful. (see below for the java server and handler class)
I gave this to my studenst today and they were blown away.

Here’s an example of a client program talking to our local area server from last week:

1.<html>
2.<head>
3.<title>A clean client</title>
4.</head>
5.<body>
6.<script>
7.xmldoc = new ActiveXObject("Msxml2.DOMDocument");
8.var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
9.var str="<?xml version=\"1.0\" ?><methodRequest><methodName>area.circleArea</methodName><params><param><value><double>22</double></value></param></params></methodRequest>"
10.xmlhttp.Open("POST","http://localhost:6655",false);
11.xmlhttp.send(str);
12.xmldoc.loadXML(xmlhttp.responseText); //load the returned stream into the dom document
13.alert(xmldoc.text)

14.</script>
15.</body>
16.</html>

Sending a stuct to the AreaServer is just as easy, here we put the code in a textarea, and use and event to trigger the call.

Replace the xml string with the contents of a text area:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>A clean client</title>
</head>
<body>
<form name="call">
<textarea name="send" cols="30" rows="15">
<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>area.anyArea</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>type</name>
<value>
<string>rectangle</string>
</value>
</member>
<member>
<name>length</name>
<value>
<double>34</double>
</value>
</member>
<member>
<name>width</name>
<value>
<double>100</double>
</value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>
</textarea>
<br />
<input type="button" onclick="sendRpc()" value="send it">
</form>
<script>
function sendRpc() {
xmldoc = new ActiveXObject("Msxml2.DOMDocument");
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
var hash=document.call.send.value
xmlhttp.Open("POST","http://localhost:6655",false);
xmlhttp.send(hash);
xmldoc.loadXML(xmlhttp.responseText); //load the returned stream into the dom document
alert(xmldoc.text)
}
</script>
</body>
</html>


Now the following allows for user input, where the query is sent from a web form and the response writes out to the same page:

1.<html>
2.<head>
3.<title>A clean client</title>
4.</head>
5.<body>
6.<form name="call">
7.<input type="text" name="send"> :How big is the circle?<br />
8.<input type="button" value="send it" onclick="sendRpc()"> <br />
9.Answer:
10.<div name="answer" id="answer"> </div>
11.</form>
12.<script>
13.function sendRpc() {
14.xmldoc = new ActiveXObject("Msxml2.DOMDocument");
15.var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
16.var query=document.call.send.value
17.var str="<?xml version=\"1.0\" ?><methodRequest><methodName>area.circleArea</methodName><params><param><value><double>"+ query +"</double></value></param></params></methodRequest>"
18.xmlhttp.Open("POST","http://localhost:6655",false);
19.xmlhttp.send(str);
20.xmldoc.loadXML(xmlhttp.responseText);
21. //load the returned stream into the dom document
22.document.all.answer.innerText=xmldoc.text
23.}
24.</script>
25.</body>
26.</html>

Ideally we would like to design a client that allowed calls to either the circle area or rectangle area handler through the area.anyArea method. The wrapping of content in an xmlrpc envelope really belongs in a library*

Assignment 2c.
Design a client that meets the above requirements. (modularization and error checking are a must!)

*. Javascript files can be saved and reused by many applications in a .js file.
The calling app need only ask for it the following way:
<script language=”JavaScript” src=”myRpcModule.js”></script>

Have FUN!!!

The cross browser hack:

1.<script>
2.function createXMLHttpRequest() {
3.try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {}
4.try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) {}
5.try { return new XMLHttpRequest(); } catch(e) {}
6.alert("XMLHttpRequest not supported");
7.return null;
8.}

9.var xmlRpcReq = createXMLHttpRequest();
10.xmlRpcReq.open("GET", "http://munro.humber.ca/~dymond/webservice/area/xml_rpc.php", false);
11.xmlRpcReq.send(null);
12.var serverResponse = xmlRpcReq.responseText;
13.alert(serverResponse);
14.xmldoc = new ActiveXObject("Msxml2.DOMDocument");
15.xmldoc.async = false;
16.xmldoc.loadXML(xmlRpcReq.responseText)
17.//boy does this get ugly…
18.digNode = xmldoc.documentElement.firstChild.firstChild.firstChild.firstChild.firstChild.firstChild.firstChild.nodeValue
19.alert(xmldoc.text)
20.alert(digNode)
21.</script>


the handler:

import java.util.*;
public class AreaHandler {

public Double rectArea(double length, double width) {
return new Double(length*width);
}

public Double circleArea(double radius) {
double value=(radius*radius*Math.PI);
return new Double (value);
}
public Double anyArea(Hashtable arguments) {
Double value;
value=new Double(0);
String requestType=(String) arguments.get("type");
if (requestType.equals("circle")) {
Double radius=(Double) (arguments.get("radius"));
value=circleArea(radius.doubleValue( ));
}
if (requestType.equals("rectangle")) {
Double length=(Double) (arguments.get("length"));
Double width=(Double) (arguments.get("width"));
value=rectArea(length.doubleValue(), width.doubleValue( ));
}
return value;
} }


the server:

import org.apache.xmlrpc.XmlRpcHandler;
import java.io.IOException;
import org.apache.xmlrpc.WebServer;
import org.apache.xmlrpc.XmlRpc;
import org.apache.xmlrpc.XmlRpcResponseProcessor;


public class AreaServer {

public static void main(String[] args) {
int listenf55;
// Start the server, using built-in version
System.out.println("Attempting to start XML-RPC Server…");
WebServer server=new WebServer(listen);
System.out.println("Started successfully.");

// Register our handler class as area
server.addHandler("area", new AreaHandler( ));
server.start();
System.out.println(
"Registered AreaHandler class to area.");

System.out.println("Now accepting requests. (Halt program to stop.)");
XmlRpcResponseProcessor xmlProc=new XmlRpcResponseProcessor();
System.out.println(listen);

}

}

now you will ahve to play around a bit, but the server talks willingly to the xmlhttp javascript, completeley rewriting the client/server model
I have included a few online hacks, but I think it opens the playing field up in a big way,
</xmp>
Eric

Comments

, Eric Dymond

see:
http://www.edymond.com/ajax.htm
or maybe this won't get filtered…it might get ugly

Intro to Ajax-XMLRPC. (I promised this a year ago…, but you know stuff happens)
I think this will enable a good deal of new art work so here goes nuthin…
<p>For many applications, developing a server side client to act as a go between
is sometimes overkill.<br>
JavaScript supports XML transport and XML parsing.<br>
The Msxml2.XMLHTTP object has support in IE and Mozilla, (See below for a cross
browser hack ).<br>
The advantage here is that the processing is done by the client and the server
just has to echo XML documents. XMLRPC is a great candidate, and the programming
model is pretty simple. A new technology, Ajax, is based on this type of asynchronous
callback.<br>
The clean client below demonstrates a communication to the server, and the return
processing by the client. As long as the processing program resides on the same
server as the client document, any security checks will be bypassed.</p>
<p>&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.01 Transitional//EN&quot;&gt;<br>
&lt;html&gt;<br>
&lt;head&gt;<br>
&lt;title&gt;A clean client&lt;/title&gt;<br>
&lt;/head&gt;<br>
&lt;body&gt;<br>
&lt;script&gt;<br>
xmldoc = new ActiveXObject(&quot;Msxml2.DOMDocument&quot;);<br>
var xmlhttp = new ActiveXObject(&quot;Msxml2.XMLHTTP&quot;);<br>
xmlhttp.Open(&quot;Get&quot;,&quot;http://munro.humber.ca/~dymond/webservice/area/xml_rpc.php",false);<br>
xmlhttp.send();<br>
xmldoc.loadXML(xmlhttp.responseText); //load the returned stream into the dom
document<br>
alert(xmldoc.xml)<br>
alert(xmldoc.text)<br>
alert(xmldoc.getElementsByTagName(&quot;int&quot;).item(1).text)<br>
&lt;/script&gt;<br>
&lt;/body&gt;<br>
&lt;/html&gt;</p>
<p>The combination of the DOM and the XMLHTTP object prove pretty powerful. (see
below for the java server and handler class)<br>
I gave this to my studenst today and they were blown away.</p>
<p>Here&#8217;s an example of a client program talking to our local area server
from last week:</p>
<p>1. &lt;html&gt;<br>
2. &lt;head&gt;<br>
3. &lt;title&gt;A clean client&lt;/title&gt;<br>
4. &lt;/head&gt;<br>
5. &lt;body&gt;<br>
6. &lt;script&gt;<br>
7. xmldoc = new ActiveXObject(&quot;Msxml2.DOMDocument&quot;);<br>
8. var xmlhttp = new ActiveXObject(&quot;Msxml2.XMLHTTP&quot;);<br>
9. var str=&quot;&lt;?xml version=&quot;1.0&quot; ?&gt;&lt;methodRequest&gt;&lt;methodName&gt;area.circleArea&lt;/methodName&gt;&lt;params&gt;&lt;param&gt;&lt;value&gt;&lt;double&gt;22&lt;/double&gt;&lt;/value&gt;&lt;/param&gt;&lt;/params&gt;&lt;/methodRequest&gt;&quot;<br>
10. xmlhttp.Open(&quot;POST&quot;,&quot;http://localhost:6655",false);<br>
11. xmlhttp.send(str);<br>
12. xmldoc.loadXML(xmlhttp.responseText); //load the returned stream into the
dom document<br>
13. alert(xmldoc.text)</p>
<p>14. &lt;/script&gt;<br>
15. &lt;/body&gt;<br>
16. &lt;/html&gt;</p>
<p>Sending a stuct to the AreaServer is just as easy, here we put the code in
a textarea, and use and event to trigger the call.</p>
<p>Replace the xml string with the contents of a text area:</p>
<p><br>
&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.01 Transitional//EN&quot;&gt;<br>
&lt;html&gt;<br>
&lt;head&gt;<br>
&lt;title&gt;A clean client&lt;/title&gt;<br>
&lt;/head&gt;<br>
&lt;body&gt;<br>
&lt;form name=&quot;call&quot;&gt;<br>
&lt;textarea name=&quot;send&quot; cols=&quot;30&quot; rows=&quot;15&quot;&gt;<br>
&lt;?xml version=&quot;1.0&quot; encoding=&quot;iso-8859-1&quot;?&gt;<br>
&lt;methodCall&gt;<br>
&lt;methodName&gt;area.anyArea&lt;/methodName&gt;<br>
&lt;params&gt;<br>
&lt;param&gt;<br>
&lt;value&gt;<br>
&lt;struct&gt;<br>
&lt;member&gt;<br>
&lt;name&gt;type&lt;/name&gt;<br>
&lt;value&gt;<br>
&lt;string&gt;rectangle&lt;/string&gt;<br>
&lt;/value&gt;<br>
&lt;/member&gt;<br>
&lt;member&gt;<br>
&lt;name&gt;length&lt;/name&gt;<br>
&lt;value&gt;<br>
&lt;double&gt;34&lt;/double&gt;<br>
&lt;/value&gt;<br>
&lt;/member&gt;<br>
&lt;member&gt;<br>
&lt;name&gt;width&lt;/name&gt;<br>
&lt;value&gt;<br>
&lt;double&gt;100&lt;/double&gt;<br>
&lt;/value&gt;<br>
&lt;/member&gt;<br>
&lt;/struct&gt;<br>
&lt;/value&gt;<br>
&lt;/param&gt;<br>
&lt;/params&gt;<br>
&lt;/methodCall&gt;<br>
&lt;/textarea&gt;<br>
&lt;br /&gt;<br>
&lt;input type=&quot;button&quot; onclick=&quot;sendRpc()&quot; value=&quot;send
it&quot;&gt;<br>
&lt;/form&gt;<br>
&lt;script&gt;<br>
function sendRpc() {<br>
xmldoc = new ActiveXObject(&quot;Msxml2.DOMDocument&quot;);<br>
var xmlhttp = new ActiveXObject(&quot;Msxml2.XMLHTTP&quot;);<br>
var hash=document.call.send.value<br>
xmlhttp.Open(&quot;POST&quot;,&quot;http://localhost:6655",false);<br>
xmlhttp.send(hash);<br>
xmldoc.loadXML(xmlhttp.responseText); //load the returned stream into the dom
document<br>
alert(xmldoc.text)<br>
}<br>
&lt;/script&gt;<br>
&lt;/body&gt;<br>
&lt;/html&gt;</p>
<p><br>
Now the following allows for user input, where the query is sent from a web
form and the response writes out to the same page:</p>
<p>1. &lt;html&gt;<br>
2. &lt;head&gt;<br>
3. &lt;title&gt;A clean client&lt;/title&gt;<br>
4. &lt;/head&gt;<br>
5. &lt;body&gt;<br>
6. &lt;form name=&quot;call&quot;&gt;<br>
7. &lt;input type=&quot;text&quot; name=&quot;send&quot;&gt; :How big is the
circle?&lt;br /&gt;<br>
8. &lt;input type=&quot;button&quot; value=&quot;send it&quot; onclick=&quot;sendRpc()&quot;&gt;
&lt;br /&gt;<br>
9. Answer:<br>
10. &lt;div name=&quot;answer&quot; id=&quot;answer&quot;&gt; &lt;/div&gt; <br>
11. &lt;/form&gt;<br>
12. &lt;script&gt;<br>
13. function sendRpc() {<br>
14. xmldoc = new ActiveXObject(&quot;Msxml2.DOMDocument&quot;);<br>
15. var xmlhttp = new ActiveXObject(&quot;Msxml2.XMLHTTP&quot;);<br>
16. var query=document.call.send.value<br>
17. var str=&quot;&lt;?xml version=&quot;1.0&quot; ?&gt;&lt;methodRequest&gt;&lt;methodName&gt;area.circleArea&lt;/methodName&gt;&lt;params&gt;&lt;param&gt;&lt;value&gt;&lt;double&gt;&quot;+
query +&quot;&lt;/double&gt;&lt;/value&gt;&lt;/param&gt;&lt;/params&gt;&lt;/methodRequest&gt;&quot;<br>
18. xmlhttp.Open(&quot;POST&quot;,&quot;http://localhost:6655",false);<br>
19. xmlhttp.send(str);<br>
20. xmldoc.loadXML(xmlhttp.responseText);<br>
21. //load the returned stream into the dom document<br>
22. document.all.answer.innerText=xmldoc.text<br>
23. }<br>
24. &lt;/script&gt;<br>
25. &lt;/body&gt;<br>
26. &lt;/html&gt;</p>
<p>Ideally we would like to design a client that allowed calls to either the circle
area or rectangle area handler through the area.anyArea method. The wrapping
of content in an xmlrpc envelope really belongs in a library*</p>
<p>Assignment 2c.<br>
Design a client that meets the above requirements. (modularization and error
checking are a must!)</p>
<p>*. Javascript files can be saved and reused by many applications in a .js file.<br>
The calling app need only ask for it the following way:<br>
&lt;script language=&#8221;JavaScript&#8221; src=&#8221;myRpcModule.js&#8221;&gt;&lt;/script&gt;</p>
<p>Have FUN!!!</p>
<p>The cross browser hack:</p>
<p>1. &lt;script&gt;<br>
2. function createXMLHttpRequest() {<br>
3. try { return new ActiveXObject(&quot;Msxml2.XMLHTTP&quot;); } catch (e) {}<br>
4. try { return new ActiveXObject(&quot;Microsoft.XMLHTTP&quot;); } catch (e)
{}<br>
5. try { return new XMLHttpRequest(); } catch(e) {}<br>
6. alert(&quot;XMLHttpRequest not supported&quot;);<br>
7. return null;<br>
8. }</p>
<p>9. var xmlRpcReq = createXMLHttpRequest();<br>
10. xmlRpcReq.open(&quot;GET&quot;, &quot;http://munro.humber.ca/~dymond/webservice/area/xml_rpc.php";,
false);<br>
11. xmlRpcReq.send(null);<br>
12. var serverResponse = xmlRpcReq.responseText;<br>
13. alert(serverResponse); <br>
14. xmldoc = new ActiveXObject(&quot;Msxml2.DOMDocument&quot;);<br>
15. xmldoc.async = false;<br>
16. xmldoc.loadXML(xmlRpcReq.responseText)<br>
17. //boy does this get ugly&#8230;<br>
18. digNode = xmldoc.documentElement.firstChild.firstChild.firstChild.firstChild.firstChild.firstChild.firstChild.nodeValue<br>
19. alert(xmldoc.text)<br>
20. alert(digNode)<br>
21. &lt;/script&gt;</p>
<p><br>
the handler:</p>
<p>import java.util.*;<br>
public class AreaHandler {</p>
<p> public Double rectArea(double length, double width) {<br>
return new Double(length*width);<br>
}</p>
<p> public Double circleArea(double radius) {<br>
double value=(radius*radius*Math.PI);<br>
return new Double (value);<br>
}<br>
public Double anyArea(Hashtable arguments) {<br>
Double value;<br>
value=new Double(0);<br>
String requestType=(String) arguments.get(&quot;type&quot;);<br>
if (requestType.equals(&quot;circle&quot;)) {<br>
Double radius=(Double) (arguments.get(&quot;radius&quot;));<br>
value=circleArea(radius.doubleValue( ));<br>
}<br>
if (requestType.equals(&quot;rectangle&quot;)) {<br>
Double length=(Double) (arguments.get(&quot;length&quot;));<br>
Double width=(Double) (arguments.get(&quot;width&quot;));<br>
value=rectArea(length.doubleValue(), width.doubleValue( ));<br>
}<br>
return value;<br>
} }</p>
<p><br>
the server:</p>
<p>import org.apache.xmlrpc.XmlRpcHandler;<br>
import java.io.IOException;<br>
import org.apache.xmlrpc.WebServer;<br>
import org.apache.xmlrpc.XmlRpc;<br>
import org.apache.xmlrpc.XmlRpcResponseProcessor;</p>
<p><br>
public class AreaServer {</p>
<p> public static void main(String[] args) {<br>
int listenf55;<br>
// Start the server, using built-in version<br>
System.out.println(&quot;Attempting to start XML-RPC Server…&quot;);<br>
WebServer server=new WebServer(listen);<br>
System.out.println(&quot;Started successfully.&quot;);</p>
<p> // Register our handler class as area<br>
server.addHandler(&quot;area&quot;, new AreaHandler( ));<br>
server.start();<br>
System.out.println(<br>
&quot;Registered AreaHandler class to area.&quot;);</p>
<p> System.out.println(&quot;Now accepting requests. (Halt program to stop.)&quot;);<br>
XmlRpcResponseProcessor xmlProc=new XmlRpcResponseProcessor();<br>
System.out.println(listen);</p>
<p> }</p>
<p>}</p>
<p>now you will ahve to play around a bit, but the server talks willingly to the
xmlhttp javascript, completeley rewriting the client/server model<br>
I have included a few online hacks, but I think it opens the playing field up
in a big way,<br>
Eric</p>

, Eric Dymond

<xmp>
so whats the big deal?
well you can easily set up xmlrpc servers in many languages.
PHP 5 has full support (see example below, I hacked this from somewhhere else), so does perl (Frontier modules), java, even c-sharp.
Now connecting and intercommunications are simplified and the promise of a community network is available to those with basic programming skills.
For artists this allows us to exchange, and interoperate in new and dynamic layers.
see the AJAX community for more info, but its not rocket science, and it is very enabling.

Eric

a php server from elsewhwere:

<?
$request=<<<END
<?xml version='1.' ?>
<methodCall>
<methodName>getRange</methodName>
<params>
<param>
<value><int>32</int>
</value>
</param>
<param>
<value>
<int>76</int>
</value>
</param>
<param>
<value>
<int>657</int>
</value>
</param>
</params>
</methodCall>
END;
$rpc_server=xmlrpc_server_create() or die("cant make one here");
xmlrpc_server_register_method($rpc_server,"getRange","phpGetRange") or die ("cant register stuff");
$response=xmlrpc_server_call_method($rpc_server,$request,NULL);
echo $response;
xmlrpc_server_destroy($rpc_server);

function phpGetRange($method,$args,$add_args) {
sort($args);
return array('start'=>$args[0], 'end'=>end($args));

}
?>

and a perl example (what a beautiful language!):
#!/usr/bin/perl
use XMLRPC::Transport::HTTP;
sub circleArea {
shift;
return (22/7)* shift;

}
my $server = XMLRPC::Transport::HTTP::CGI
-> dispatch_to('circleArea')
-> handle
;


</xmp>

, Jason Van Anden

Eric! Thank You!
That was incredibly generous and helpful, and probably one of the bestpresentations of this technology I have found online.
I encourage everyone to give this (at least) an hour of their time -as Eric points out, the technology is not rocket science, and once youunderstand it the potential is super far reaching.
A good example (and blantant self promotion) can be found here:
link: http://tax.cf.huffingtonpost.commore memorable link: http://www.endlesslist.com
"Tax the Rich!" uses loads XML from the server to refresh the randomwords that appear over Baby Liberty's head. This could have been hardcoded into the javascript that drives this, but the XML makes it soooomuch easier to maintain (since I am adding these whenever the moodstrikes me). This is the equivalent to a "Hello World" styleexample.
Tax the Rich!Jason Van Anden


On 2/3/06, Eric Dymond <[email protected]> wrote:> <xmp>> so whats the big deal?> well you can easily set up xmlrpc servers in many languages.> PHP 5 has full support (see example below, I hacked this from somewhhere else), so does perl (Frontier modules), java, even c-sharp.> Now connecting and intercommunications are simplified and the promise of a community network is available to those with basic programming skills.> For artists this allows us to exchange, and interoperate in new and dynamic layers.> see the AJAX community for more info, but its not rocket science, and it is very enabling.>> Eric>> a php server from elsewhwere:>> <?> $request=<<<END> <?xml version='1.' ?>> <methodCall>> <methodName>getRange</methodName>> <params>> <param>> <value><int>32</int>> </value>> </param>> <param>> <value>> <int>76</int>> </value>> </param>> <param>> <value>> <int>657</int>> </value>> </param>> </params>> </methodCall>> END;> $rpc_server=xmlrpc_server_create() or die("cant make one here");> xmlrpc_server_register_method($rpc_server,"getRange","phpGetRange") or die ("cant register stuff");> $response=xmlrpc_server_call_method($rpc_server,$request,NULL);> echo $response;> xmlrpc_server_destroy($rpc_server);>> function phpGetRange($method,$args,$add_args) {> sort($args);> return array('start'=>$args[0], 'end'=>end($args));>> }> ?>>> and a perl example (what a beautiful language!):> #!/usr/bin/perl> use XMLRPC::Transport::HTTP;> sub circleArea {> shift;> return (22/7)* shift;>> }> my $server = XMLRPC::Transport::HTTP::CGI> -> dispatch_to('circleArea')> -> handle> ;>>> </xmp>> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>

–Jason Van Andenhttp://www.smileproject.com

, Eric Dymond

Jason Van Anden wrote:

> Eric! Thank You!
Your welcome, thanks for the comment!
<xmp>
If you have access to root on your server, a simple chat server is easy to establish.
You will need to add the xmlrpc classes to your classpath, but thats trivial.
This could use some flags for user names etc., but it gives a simple web page the
same functionality as any chat client, and it could be your personal chat server.
The xmlrpc classes are available for download from apache.org (search for xmlrpc)
The nice thing about java is that it's a stateful server (short and sweet)


/*
* ChatServer.java
*
* Created on February 3, 2006, 12:21 PM
*/

package rpcserver;
/*
* ChatRpc.java
*
* Created on February 3, 2006, 12:19 PM
*/

package rpcserver;

/**
*
* @author dymond
*/
public class ChatRpc {
protected String value;

public ChatRpc(String initialValue) {
value=initialValue;
}

public String getValue(String requester) {
return value;
}

public String setValue(String requester, String newValue) {
value=newValue;
return value;
}
}



/**
*
* @author dymond
*/
import org.apache.xmlrpc.XmlRpcHandler;
import java.io.IOException;
import org.apache.xmlrpc.WebServer;
import org.apache.xmlrpc.XmlRpc;

public class ChatServer {

public static void main(String[] args) {
System.out.println("Attempting to start XML-RPC Server…");
WebServer server = new WebServer(8024);
server.start();
System.out.println("Started successfully.");

// Register our handler class as area
server.addHandler("getSet", new ChatRpc("welcome to chatland"));
System.out.println(
"Registered ChatRpc class to getSet.");

System.out.println("Now accepting requests. (Halt program to stop.)");

}
}

Now for the clients. On PC's this requires the ActiveX call, but I have run a similar program in Opera on a Mac without a hitch. You can check out my hack from the previous post or use Suns example (link is on the front page of www.sun.com).
There's no great net Artsits, just a lot of helpful people. Ego vs Super Ego (sorry Steve Dietz)

<html>
<head>
<title>A clean client</title>
</head>
<body>
<form name="call">
<input type="text" name="send"> :Lets Talk<br />
<input type="button" value="send it" onclick="sendRpc()"> <br />
Answer:
<div name="answer" id="answer" style="background-color:wheat"> </div>
</form>
<script>
function sendRpc() {
xmldoc = new ActiveXObject("Msxml2.DOMDocument");
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
var query=document.call.send.value
var str_set="<?xml version=\"1.0\" ?><methodRequest><methodName>getChat</methodName><params><param><value><string>set</string></value></param><param><value><string>"+ query +"</string></value></param></params></methodRequest>"
var str_get="<?xml version=\"1.0\" ?><methodRequest><methodName>getChat</methodName><params><param><value><string>"+ query +"</string></value></param></params></methodRequest>"
//these comments are for set and get options
//xmlhttp.Open("POST","http://localhost:4455",false);
//xmlhttp.send(str_get);

//xmldoc.loadXML(xmlhttp.responseText);
//load the returned stream into the dom document

xmlhttp.Open("POST","http://www.yourserver.com:8024",false);
xmlhttp.send(str_set);
xmldoc.loadXML(xmlhttp.responseText);
//load the returned stream into the dom document

document.all.answer.innerHTML+=(xmldoc.text+"<br />");

}
</script>
</body>
</html>
</xmp>

, Eric Dymond

Ooops
just in case you get driven nuts,
for the java xml rpc envelope, amke sure you point to the calls and then the method in the javascript client:
eg:
function sendRpc() {
xmldoc = new ActiveXObject("Msxml2.DOMDocument");
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
var query=document.call.send.value
var str_set="<?xml version=\"1.0\" ?><methodRequest><methodName>getSet.setValue</methodName><params><param><value><string>set</string></value></param><param><value><string>"+ query +"</string></value></param></params></methodRequest>"
var str_get="<?xml version=\"1.0\" ?><methodRequest><methodName>getSet.getValue</methodName><params><param><value><string>"+ query +"</string></value></param></params></methodRequest>"
//xmlhttp.Open("POST","http://localhost:4455",false);
//xmlhttp.send(str_get);
etc.. etc…
Eric

, Myron Turner

I was very interested in these posts concerning Ajax, which I hadn't heard of before, although I was aware of the possible interactive use of XML, i.e. read about it but never tried it out. But you sparked my interest and I found useful links at

http://en.wikipedia.org/wiki/AJAX

While Ajax refers to a particular technology, ie. Javascript in combination with XML and behind the scenes server access that can be parsed using the DOM, the purpose of Ajax, as I understand it, is independent of any particular technology.

"The intent is to shift a great deal of interaction to the Web surfer's computer, exchanging data with the server behind the scenes, so that the entire Web page does not have to be reloaded each time the user makes a change. This is meant to increase the Web page's interactivity, speed, and usability." – from wikipedia

This is a practice which I've been interested in for some time, most recently in Bstat Zero at http://www.bstatzero.org/bstat, where using php and perl and both hidden and visible frames, I create a user interface that remains constant, while a great deal of data is loaded into the hidden frames and accessed by the user interface.

There are basically two kinds of hidden data–javscript and html, each of which is accessed on an as needed basis. When a major new access is made from the visible screen this hidden data changes. But otherwise, it reamins behind when the visible screen updates data from the server.

The aim was to give the user some feeling that this is a like a desktop application, and depending on how fast your connection is and how great a load of data has to be fetched from the server, it often has the feel of a desktop app.

A big difference between Ajax and what I've been doing is that Ajax may put a bigger demand on the borwser. The data I load into the hidden frames is already pre-cooked, but with Ajax I assume you have to parse the input stream. I found that I had to make changes to bstat when I put too much of a demand on the browser–even with a fairly powerful machine. So, that is a consideration.



Myron Turner
http://www.room535.org
http://www.bstatzero.org

, Eric Dymond

Myron Turner wrote:

> I was very interested in these posts concerning Ajax, which I hadn't
> heard of before, although I was aware of the possible interactive use
> of XML, i.e. read about it but never tried it out. But you sparked my
> interest and I found useful links at
>
> http://en.wikipedia.org/wiki/AJAX
>
> While Ajax refers to a particular technology, ie. Javascript in
> combination with XML and behind the scenes server access that can be
> parsed using the DOM, the purpose of Ajax, as I understand it, is
> independent of any particular technology.
>
> "The intent is to shift a great deal of interaction to the Web
> surfer's computer, exchanging data with the server behind the scenes,
> so that the entire Web page does not have to be reloaded each time the
> user makes a change. This is meant to increase the Web page's
> interactivity, speed, and usability." – from wikipedia
>
> This is a practice which I've been interested in for some time, most
> recently in Bstat Zero at http://www.bstatzero.org/bstat, where using
> php and perl and both hidden and visible frames, I create a user
> interface that remains constant, while a great deal of data is loaded
> into the hidden frames and accessed by the user interface.
>
> There are basically two kinds of hidden data–javscript and html, each
> of which is accessed on an as needed basis. When a major new access
> is made from the visible screen this hidden data changes. But
> otherwise, it reamins behind when the visible screen updates data from
> the server.
>
> The aim was to give the user some feeling that this is a like a
> desktop application, and depending on how fast your connection is and
> how great a load of data has to be fetched from the server, it often
> has the feel of a desktop app.
>
> A big difference between Ajax and what I've been doing is that Ajax
> may put a bigger demand on the borwser. The data I load into the
> hidden frames is already pre-cooked, but with Ajax I assume you have
> to parse the input stream. I found that I had to make changes to
> bstat when I put too much of a demand on the browser–even with a
> fairly powerful machine. So, that is a consideration.
There are some important considerations when you decide to use Ajax.
The most important is latency.
I have found that the javascript calls reduce the round trip for the client.
The reason being that the entire web page doesn't have to rebuild state, just the javascript callback. Only the javascript layer makes the query, the page remains in state.
From a design view, this offers a very different design model.
Current design models require the server to re-emit the page in it's entirety. The javascript callback keeps the page in state, no flicker or refresh issues.
Since the model is so new, it will evolve. Current clients require little memory usage on the browser.
I think the AJAX model is a big improvement on the current client/server model.
Current browsers use very little memory and computation.
I can't see complex AJAX apps causing a memory issue on the browser side.

Time will tell, but all the major techs (java, ruby, python) are moving quickly to this model for a good reason. It really does open up possibilities that escaped us before.
Eric


>
>
>
> Myron Turner
> http://www.room535.org
> http://www.bstatzero.org

, Eric Dymond

I should add that using java or python on a normally unoccupied port such as 44567 makes the callbacks extremely fast, as there seems to be less competition for requests and responses.
Eric

, Myron Turner

Eric Dymond wrote:

> Myron Turner wrote:
>
> > "The intent is to shift a great deal of interaction to the Web
> > surfer's computer, exchanging data with the server behind the
> scenes,
> > so that the entire Web page does not have to be reloaded each time
> the
> > user makes a change. This is meant to increase the Web page's
> > interactivity, speed, and usability." – from wikipedia
> >
> > This is a practice which I've been interested in for some time, most
> > recently in Bstat Zero at http://www.bstatzero.org/bstat, where
> using
> > php and perl and both hidden and visible frames, I create a user
> > interface that remains constant, while a great deal of data is
> loaded
> > into the hidden frames and accessed by the user interface.
> >

> I have found that the javascript calls reduce the round trip for the
> client.
> The reason being that the entire web page doesn't have to rebuild
> state, just the javascript callback. Only the javascript layer makes
> the query, the page remains in state.
> From a design view, this offers a very different design model.
> Current design models require the server to re-emit the page in it's
> entirety. The javascript callback keeps the page in state, no flicker
> or refresh issues.
>
> Eric
> >


Yes, this is very attractive. If you take a look at bstatzero you'll see that there's no flicker, because much of the data is already on the browser in the hidden frames. But what I've done there is relatively more static than what Ajax enables, which is a very focused updating of data and the screen. I did something more like it in a piece called "Old News" some years ago, which constantly updates headlines to the screen.
http://www.room535.org/meditations/meditation_frame.html
It loads an array of headlines and front page images from a selected newspaper and when it comes to the end of the array, it fetches headlines and images from the next paper. It's totally transparent to the user. I haven't kept up with the changes in style of the newspapers. I see it's still picking up headlines from the NY Times but stops when it gets to the Washington Post.

Myron

, Dirk Vekemans

Afaik the AJAX thing is only new in the sense that it's a systematisation of
existing javascript techniques to further the rendering of xml in an
appropiate client-side way. It offers an interesting alternative for doing
more with your server resources on the client side and as you've shown with
your excellent example code you don't need to go deep into server-side
programming to accomplish a lot with it.That's excellent for artists to get
what they want without too much fuzz.
Professionally, i've been hesitant to jump the Ajax wagon because i'm in
the habit of turning to Flash for any client-side processing, and Flash
ofcourse in that context is just prepackaged javascript with the advantage
that there's a large userbase developing all kinds of classes to handle your
xml stuff. A major disadvantage with Flash is the slowness of parcing xml,
it's a real bottleneck, although it has improved somewhat in the recent
versions of the player, i gather. That's why i prefer to roll out the data
for Flash from the server with java binding classes, that really makes for a
speedy combination and you can rebalance the processing load
(server-client)anytime you run into trouble. There's lot's of examples of
this Flash/xml/java model in my Cathedral, the monAd blog system is built on
it (http://www.vilt.net/nkdee/monads/) and there's the rather noisy
experiment at http://www.vilt.net/nkdee/kids.jsp (unfinished like nearly
everything) that has a basic idea similar to Myron's Animal Locomotion (wow
Myron, some serious work you got there! Too bad the stats app is for Linux
servers only, i'm commercially hooked to a windoze host).

Ofcourse my own prefs are very relative in value (i actually enjoy its
complexity, there's a sense of delicacy to it), you can't do much this way
if you don't use some tools like Altova's xmlSpy suite to generate the Java
code for you, you 've got the trouble with Macromedia changing players every
year, so there's a lot of mess you need to be aware of, and AJAX sure is a
much cleaner, straightforward approach in this.

I can't see why an AJAX solution could avoid overloading the client at some
point, though. You won't notice anything going wrong developing easily, but
as your app scales up you'll reach the limit there soon enough. The whole
thing is about balancing the workload, always has been, always will. So
sure, AJAX 's a good thing as long as you don't expect it to solve all of
your problems…

greetz,
dv

Dirk Vekemans, poet - freelance webprogrammer,
Central Authoring Process of the
Neue Kathedrale des erotischen Elends
http://www.vilt.net/nkdee

[email protected]

http://www.vilt.net
http://www.viltdigitalvision.com



> —–Oorspronkelijk bericht—–
> Van: [email protected] [mailto:[email protected]]
> Namens Eric Dymond
> Verzonden: zondag 5 februari 2006 6:07
> Aan: [email protected]
> Onderwerp: RHIZOME_RAW: Re: Re: AJAX for artists
>
> Myron Turner wrote:
>
> > I was very interested in these posts concerning Ajax, which
> I hadn't
> > heard of before, although I was aware of the possible
> interactive use
> > of XML, i.e. read about it but never tried it out. But you
> sparked my
> > interest and I found useful links at
> >
> > http://en.wikipedia.org/wiki/AJAX
> >
> > While Ajax refers to a particular technology, ie. Javascript in
> > combination with XML and behind the scenes server access
> that can be
> > parsed using the DOM, the purpose of Ajax, as I understand it, is
> > independent of any particular technology.
> >
> > "The intent is to shift a great deal of interaction to the Web
> > surfer's computer, exchanging data with the server behind
> the scenes,
> > so that the entire Web page does not have to be reloaded
> each time the
> > user makes a change. This is meant to increase the Web page's
> > interactivity, speed, and usability." – from wikipedia
> >
> > This is a practice which I've been interested in for some
> time, most
> > recently in Bstat Zero at http://www.bstatzero.org/bstat,
> where using
> > php and perl and both hidden and visible frames, I create a user
> > interface that remains constant, while a great deal of data
> is loaded
> > into the hidden frames and accessed by the user interface.
> >
> > There are basically two kinds of hidden data–javscript and
> html, each
> > of which is accessed on an as needed basis. When a major
> new access
> > is made from the visible screen this hidden data changes. But
> > otherwise, it reamins behind when the visible screen
> updates data from
> > the server.
> >
> > The aim was to give the user some feeling that this is a like a
> > desktop application, and depending on how fast your
> connection is and
> > how great a load of data has to be fetched from the server,
> it often
> > has the feel of a desktop app.
> >
> > A big difference between Ajax and what I've been doing is that Ajax
> > may put a bigger demand on the borwser. The data I load into the
> > hidden frames is already pre-cooked, but with Ajax I assume
> you have
> > to parse the input stream. I found that I had to make changes to
> > bstat when I put too much of a demand on the browser–even with a
> > fairly powerful machine. So, that is a consideration.
> There are some important considerations when you decide to use Ajax.
> The most important is latency.
> I have found that the javascript calls reduce the round trip
> for the client.
> The reason being that the entire web page doesn't have to
> rebuild state, just the javascript callback. Only the
> javascript layer makes the query, the page remains in state.
> From a design view, this offers a very different design model.
> Current design models require the server to re-emit the page
> in it's entirety. The javascript callback keeps the page in
> state, no flicker or refresh issues.
> Since the model is so new, it will evolve. Current clients
> require little memory usage on the browser.
> I think the AJAX model is a big improvement on the current
> client/server model.
> Current browsers use very little memory and computation.
> I can't see complex AJAX apps causing a memory issue on the
> browser side.
>
> Time will tell, but all the major techs (java, ruby, python)
> are moving quickly to this model for a good reason. It really
> does open up possibilities that escaped us before.
> Eric
>
>
> >
> >
> >
> > Myron Turner
> > http://www.room535.org
> > http://www.bstatzero.org
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe:
> http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in
> the Membership Agreement available online at
> http://rhizome.org/info/29.php
>

, Plasma Studii

>You will need to add the xmlrpc classes to your classpath, but thats trivial.


hey eric,

probably, i'm just not getting this, but seems like the same result would be SO much easier with PHP? PHP is super clear, whereas Ajax just isn't at all. It's kinda the diff between intuitive and memorized. most folks don't even notice how much they memorize(as opposed to understand), but a lot seem like just arbitrary steps. sorta why reading/writing C is actually FAR more intuitively comprehensible (though compilers are usually convoluted) than anything in Flash.

the steps to write to a file (any file on the web, not just XML) in PHP are clear. seems it would be a lot more "available to artists"? is there some perk i'm missing here? Seems like bafflingly convoluted MS design?




<?

$FileOpen = fopen( "anything.txt", "w" ); // specify file to write to
if ( $FileOpen ) {
fwrite( $FileOpen, "write whatever you want, including HTML, XML or javascript code" );
}

?>


that's ALL the code it takes!

upload it to a server running php (and about all of em do) this shows up on the page (or it's included with osX, a download, etc). the code doesn't. if the page doesn't exist, it'll create it (though there's also a file_exists() function you can use if you don't want that to happen) the php could go absolutely anywhere on your HTML page. just name it x.php instead of x.html. it's designed with the coder in mind, not the code (which is why i say an MS thing, they seem to be incapable of thinking any way but from their own perspective)


reminds me of depreciating the <center> tag. what possible improvement could you make by replacing it?! if it's off by a pixel one in a thousand times, who cares?! (Web design just isn't print design and CSS and XHTML are just blatantly dumb code design) the tag is well worth it just because it works so clearly and without memorizing. Design utility extends to a lot more than just Italian coffee makers and German cars. Code is another appliance.

, Pall Thayer

I think you're missing the point. It's not the ability to read or
write data to the server but the ability to do so in a way that
doesn't require reloading the entire page. Lets say person A in
Arkansas does something on the page that rewrites the data in your
anything.txt file. Person B in Botswana isn't going to see those
changes unless they reload the page. AJAX lets you do the reloading
in the background. Probably the best use of AJAX to this day, and
almost certainly a contributing factor to it's renewed rise to
stardom (it's been around for a while) is Google maps. It has
revolutionized the way maps are presented on the web. The interface
is absolutely brilliant and a huge leap away from the old method of
clicking on N, E, S or W to reload an image.

Palli

On 5.2.2006, at 10:09, Plasma Studii wrote:

>> You will need to add the xmlrpc classes to your classpath, but
>> thats trivial.
>
>
> hey eric,
>
> probably, i'm just not getting this, but seems like the same result
> would be SO much easier with PHP? PHP is super clear, whereas Ajax
> just isn't at all. It's kinda the diff between intuitive and
> memorized. most folks don't even notice how much they memorize(as
> opposed to understand), but a lot seem like just arbitrary steps.
> sorta why reading/writing C is actually FAR more intuitively
> comprehensible (though compilers are usually convoluted) than
> anything in Flash.
>
> the steps to write to a file (any file on the web, not just XML) in
> PHP are clear. seems it would be a lot more "available to
> artists"? is there some perk i'm missing here? Seems like
> bafflingly convoluted MS design?
>
>
>
>
> <?
>
> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write to
> if ( $FileOpen ) {
> fwrite( $FileOpen, "write whatever you want, including HTML, XML
> or javascript code" );
> }
>
> ?>
>
>
> that's ALL the code it takes!
>
> upload it to a server running php (and about all of em do) this
> shows up on the page (or it's included with osX, a download, etc).
> the code doesn't. if the page doesn't exist, it'll create it
> (though there's also a file_exists() function you can use if you
> don't want that to happen) the php could go absolutely anywhere on
> your HTML page. just name it x.php instead of x.html. it's
> designed with the coder in mind, not the code (which is why i say
> an MS thing, they seem to be incapable of thinking any way but from
> their own perspective)
>
>
> reminds me of depreciating the <center> tag. what possible
> improvement could you make by replacing it?! if it's off by a
> pixel one in a thousand times, who cares?! (Web design just isn't
> print design and CSS and XHTML are just blatantly dumb code
> design) the tag is well worth it just because it works so clearly
> and without memorizing. Design utility extends to a lot more than
> just Italian coffee makers and German cars. Code is another
> appliance.
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php
>




Pall Thayer
[email protected]
http://www.this.is/pallit

, Plasma Studii

just so everybody's clear on it, on the same page, XML is not really a technology as much as a convention. this may be stuff you (the reader) realize, but seems not all do.


adding the />s won't make any difference to the HTML readers, so XML absolutely, literally is HTML, but with a few extra symbols thrown in where it won't bother a web page. it is all entirely adding conventions, nothing mechanical/practical (as in "practice" not utility). but RSS readers look for standardized HTML. it's a tedious sollution, not an "elegant" one and also a "systemization" of something that previously existed. but that applies to most everything in consumer computer technology in the last 7 years. even most of the stuff you see from WIRED, MIT or NASA.

Converting text to ASCII numbers was a development. sending info over the web in redundant "packets" for verifying the re-assembly of them was a development. adding time-based compression, as opposed to only pixel-location-based was a development. but those happened years ago.

RSS isn't actually any profound improvement over bookmarks. whether you look at it mathematically or neurologically, a person reads headlines whenever they direct their focus and auto-downloading makes no ultimate difference. (just as the usefulness of express stops in the NY subway depends entirely on the number of cars running. Usually, you wait longer for the 2,3 than yoyu save by skipping stops.) or a blog is actually not much different, only far more complicated to use, a less clear layout for readers, than an old fashioned bulletin board.

writing them from scratch is pretty easy and there's no point in using pre-fab blogware. it force fits your organization to what they think the average person needs. creativity isn't impossible, but blogs discourage it by making it a multi-step process where it was effortless, required no conscious thought. dreamweaver does that plus auto-generates convoluted ways to script because it has a lot less logic built in than we humans do.

learning code shouldn't be a dauting task at all, it is like everyone being expected to be comfortable making change in their country's currency (the US is pretty easy but the UK is tough) or using a phone. much more complicated. try explaining it to a kid for the first time. we gradually over years, figure it out, then forget we didn't know.


most often, developers use XML to act like a simplified database. but a simple text file would serve the same purpose. a hard return instead of "<category>…</category>". unless your dealing with a huge inventory or 1000 name mailing list, the whole word "database" really only serves as fashion.

the biggest difference is Flash. but the whole "parent, sibling" thing of XML is pointless if you use any (far simpler) tool. There are a ton of things that will read the text from a URL. Flash's XML reader is handy because it is really such a moron. it doesn't have any idea what that text is. what is XML. so you can actually read or write anything, and it'll think this must be one big long attribute. just write the text to whatever.xml



Dirk Vekemans wrote:

> Afaik the AJAX thing is only new in the sense that it's a
> systematisation of
> existing javascript techniques to further the rendering of xml in an
> appropiate client-side way. It offers an interesting alternative for
> doing
> more with your server resources on the client side and as you've shown
> with
> your excellent example code you don't need to go deep into server-side
> programming to accomplish a lot with it.That's excellent for artists
> to get
> what they want without too much fuzz.
> Professionally, i've been hesitant to jump the Ajax wagon because i'm
> in
> the habit of turning to Flash for any client-side processing, and
> Flash
> ofcourse in that context is just prepackaged javascript with the
> advantage
> that there's a large userbase developing all kinds of classes to
> handle your
> xml stuff. A major disadvantage with Flash is the slowness of parcing
> xml,
> it's a real bottleneck, although it has improved somewhat in the
> recent
> versions of the player, i gather. That's why i prefer to roll out the
> data
> for Flash from the server with java binding classes, that really makes
> for a
> speedy combination and you can rebalance the processing load
> (server-client)anytime you run into trouble. There's lot's of
> examples of
> this Flash/xml/java model in my Cathedral, the monAd blog system is
> built on
> it (http://www.vilt.net/nkdee/monads/) and there's the rather noisy
> experiment at http://www.vilt.net/nkdee/kids.jsp (unfinished like
> nearly
> everything) that has a basic idea similar to Myron's Animal Locomotion
> (wow
> Myron, some serious work you got there! Too bad the stats app is for
> Linux
> servers only, i'm commercially hooked to a windoze host).
>
> Ofcourse my own prefs are very relative in value (i actually enjoy its
> complexity, there's a sense of delicacy to it), you can't do much this
> way
> if you don't use some tools like Altova's xmlSpy suite to generate the
> Java
> code for you, you 've got the trouble with Macromedia changing players
> every
> year, so there's a lot of mess you need to be aware of, and AJAX sure
> is a
> much cleaner, straightforward approach in this.
>
> I can't see why an AJAX solution could avoid overloading the client at
> some
> point, though. You won't notice anything going wrong developing
> easily, but
> as your app scales up you'll reach the limit there soon enough. The
> whole
> thing is about balancing the workload, always has been, always will.
> So
> sure, AJAX 's a good thing as long as you don't expect it to solve all
> of
> your problems…
>
> greetz,
> dv
>
> Dirk Vekemans, poet - freelance webprogrammer,
> Central Authoring Process of the
> Neue Kathedrale des erotischen Elends
> http://www.vilt.net/nkdee
>
> [email protected]
>
> http://www.vilt.net
> http://www.viltdigitalvision.com
>
>
>
> > —–Oorspronkelijk bericht—–
> > Van: [email protected] [mailto:[email protected]]
> > Namens Eric Dymond
> > Verzonden: zondag 5 februari 2006 6:07
> > Aan: [email protected]
> > Onderwerp: RHIZOME_RAW: Re: Re: AJAX for artists
> >
> > Myron Turner wrote:
> >
> > > I was very interested in these posts concerning Ajax, which
> > I hadn't
> > > heard of before, although I was aware of the possible
> > interactive use
> > > of XML, i.e. read about it but never tried it out. But you
> > sparked my
> > > interest and I found useful links at
> > >
> > > http://en.wikipedia.org/wiki/AJAX
> > >
> > > While Ajax refers to a particular technology, ie. Javascript in
> > > combination with XML and behind the scenes server access
> > that can be
> > > parsed using the DOM, the purpose of Ajax, as I understand it, is
> > > independent of any particular technology.
> > >
> > > "The intent is to shift a great deal of interaction to the Web
> > > surfer's computer, exchanging data with the server behind
> > the scenes,
> > > so that the entire Web page does not have to be reloaded
> > each time the
> > > user makes a change. This is meant to increase the Web page's
> > > interactivity, speed, and usability." – from wikipedia
> > >
> > > This is a practice which I've been interested in for some
> > time, most
> > > recently in Bstat Zero at http://www.bstatzero.org/bstat,
> > where using
> > > php and perl and both hidden and visible frames, I create a user
> > > interface that remains constant, while a great deal of data
> > is loaded
> > > into the hidden frames and accessed by the user interface.
> > >
> > > There are basically two kinds of hidden data–javscript and
> > html, each
> > > of which is accessed on an as needed basis. When a major
> > new access
> > > is made from the visible screen this hidden data changes. But
> > > otherwise, it reamins behind when the visible screen
> > updates data from
> > > the server.
> > >
> > > The aim was to give the user some feeling that this is a like a
> > > desktop application, and depending on how fast your
> > connection is and
> > > how great a load of data has to be fetched from the server,
> > it often
> > > has the feel of a desktop app.
> > >
> > > A big difference between Ajax and what I've been doing is that
> Ajax
> > > may put a bigger demand on the borwser. The data I load into the
> > > hidden frames is already pre-cooked, but with Ajax I assume
> > you have
> > > to parse the input stream. I found that I had to make changes to
> > > bstat when I put too much of a demand on the browser–even with a
> > > fairly powerful machine. So, that is a consideration.
> > There are some important considerations when you decide to use Ajax.
> > The most important is latency.
> > I have found that the javascript calls reduce the round trip
> > for the client.
> > The reason being that the entire web page doesn't have to
> > rebuild state, just the javascript callback. Only the
> > javascript layer makes the query, the page remains in state.
> > From a design view, this offers a very different design model.
> > Current design models require the server to re-emit the page
> > in it's entirety. The javascript callback keeps the page in
> > state, no flicker or refresh issues.
> > Since the model is so new, it will evolve. Current clients
> > require little memory usage on the browser.
> > I think the AJAX model is a big improvement on the current
> > client/server model.
> > Current browsers use very little memory and computation.
> > I can't see complex AJAX apps causing a memory issue on the
> > browser side.
> >
> > Time will tell, but all the major techs (java, ruby, python)
> > are moving quickly to this model for a good reason. It really
> > does open up possibilities that escaped us before.
> > Eric
> >
> >
> > >
> > >
> > >
> > > Myron Turner
> > > http://www.room535.org
> > > http://www.bstatzero.org
> > +
> > -> post: [email protected]
> > -> questions: [email protected]
> > -> subscribe/unsubscribe:
> > http://rhizome.org/preferences/subscribe.rhiz
> > -> give: http://rhizome.org/support
> > +
> > Subscribers to Rhizome are subject to the terms set out in
> > the Membership Agreement available online at
> > http://rhizome.org/info/29.php
> >
>
>

, Plasma Studii

you can do the very same thing with PHP (or Perl 10+ years ago). Ajax, Perl etc still read the whole page, but can be told to load only part of it?




Pall Thayer wrote:

> I think you're missing the point. It's not the ability to read or
> write data to the server but the ability to do so in a way that
> doesn't require reloading the entire page. Lets say person A in
> Arkansas does something on the page that rewrites the data in your
> anything.txt file. Person B in Botswana isn't going to see those
> changes unless they reload the page. AJAX lets you do the reloading
> in the background. Probably the best use of AJAX to this day, and
> almost certainly a contributing factor to it's renewed rise to
> stardom (it's been around for a while) is Google maps. It has
> revolutionized the way maps are presented on the web. The interface
> is absolutely brilliant and a huge leap away from the old method of
> clicking on N, E, S or W to reload an image.
>
> Palli
>
> On 5.2.2006, at 10:09, Plasma Studii wrote:
>
> >> You will need to add the xmlrpc classes to your classpath, but
> >> thats trivial.
> >
> >
> > hey eric,
> >
> > probably, i'm just not getting this, but seems like the same result
>
> > would be SO much easier with PHP? PHP is super clear, whereas Ajax
>
> > just isn't at all. It's kinda the diff between intuitive and
> > memorized. most folks don't even notice how much they memorize(as
> > opposed to understand), but a lot seem like just arbitrary steps.
> > sorta why reading/writing C is actually FAR more intuitively
> > comprehensible (though compilers are usually convoluted) than
> > anything in Flash.
> >
> > the steps to write to a file (any file on the web, not just XML) in
>
> > PHP are clear. seems it would be a lot more "available to
> > artists"? is there some perk i'm missing here? Seems like
> > bafflingly convoluted MS design?
> >
> >
> >
> >
> > <?
> >
> > $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
> to
> > if ( $FileOpen ) {
> > fwrite( $FileOpen, "write whatever you want, including HTML, XML
> > or javascript code" );
> > }
> >
> > ?>
> >
> >
> > that's ALL the code it takes!
> >
> > upload it to a server running php (and about all of em do) this
> > shows up on the page (or it's included with osX, a download, etc).
>
> > the code doesn't. if the page doesn't exist, it'll create it
> > (though there's also a file_exists() function you can use if you
> > don't want that to happen) the php could go absolutely anywhere on
>
> > your HTML page. just name it x.php instead of x.html. it's
> > designed with the coder in mind, not the code (which is why i say
> > an MS thing, they seem to be incapable of thinking any way but from
>
> > their own perspective)
> >
> >
> > reminds me of depreciating the <center> tag. what possible
> > improvement could you make by replacing it?! if it's off by a
> > pixel one in a thousand times, who cares?! (Web design just isn't
> > print design and CSS and XHTML are just blatantly dumb code
> > design) the tag is well worth it just because it works so clearly
> > and without memorizing. Design utility extends to a lot more than
> > just Italian coffee makers and German cars. Code is another
> > appliance.
> > +
> > -> post: [email protected]
> > -> questions: [email protected]
> > -> subscribe/unsubscribe: http://rhizome.org/preferences/
> > subscribe.rhiz
> > -> give: http://rhizome.org/support
> > +
> > Subscribers to Rhizome are subject to the terms set out in the
> > Membership Agreement available online at http://rhizome.org/info/
> > 29.php
> >
>
>
>
> –
> Pall Thayer
> [email protected]
> http://www.this.is/pallit
>
>
>
>

, Plasma Studii

for most of us, we're not dealing with thousands of pieces of info.

it'd make sense for google to use a db, no need to read every map. there must be thousands. but why use Ajax to read em, when there are far more straight foreward ways? we don't have any use for the features Google needs, but if we really do want em, they they are easy to find.


here's how to read the 3rd line (start from 0) only of a page. loads nothing.


$Open = fopen("somePath/somePage.whatever", "r");
if ($Open) {
$Data = file ($Path);
$Line3 = $Data[2];
}


am still baffled?????




Pall Thayer wrote:

> I think you're missing the point. It's not the ability to read or
> write data to the server but the ability to do so in a way that
> doesn't require reloading the entire page. Lets say person A in
> Arkansas does something on the page that rewrites the data in your
> anything.txt file. Person B in Botswana isn't going to see those
> changes unless they reload the page. AJAX lets you do the reloading
> in the background. Probably the best use of AJAX to this day, and
> almost certainly a contributing factor to it's renewed rise to
> stardom (it's been around for a while) is Google maps. It has
> revolutionized the way maps are presented on the web. The interface
> is absolutely brilliant and a huge leap away from the old method of
> clicking on N, E, S or W to reload an image.
>
> Palli
>
> On 5.2.2006, at 10:09, Plasma Studii wrote:
>
> >> You will need to add the xmlrpc classes to your classpath, but
> >> thats trivial.
> >
> >
> > hey eric,
> >
> > probably, i'm just not getting this, but seems like the same result
>
> > would be SO much easier with PHP? PHP is super clear, whereas Ajax
>
> > just isn't at all. It's kinda the diff between intuitive and
> > memorized. most folks don't even notice how much they memorize(as
> > opposed to understand), but a lot seem like just arbitrary steps.
> > sorta why reading/writing C is actually FAR more intuitively
> > comprehensible (though compilers are usually convoluted) than
> > anything in Flash.
> >
> > the steps to write to a file (any file on the web, not just XML) in
>
> > PHP are clear. seems it would be a lot more "available to
> > artists"? is there some perk i'm missing here? Seems like
> > bafflingly convoluted MS design?
> >
> >
> >
> >
> > <?
> >
> > $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
> to
> > if ( $FileOpen ) {
> > fwrite( $FileOpen, "write whatever you want, including HTML, XML
> > or javascript code" );
> > }
> >
> > ?>
> >
> >
> > that's ALL the code it takes!
> >
> > upload it to a server running php (and about all of em do) this
> > shows up on the page (or it's included with osX, a download, etc).
>
> > the code doesn't. if the page doesn't exist, it'll create it
> > (though there's also a file_exists() function you can use if you
> > don't want that to happen) the php could go absolutely anywhere on
>
> > your HTML page. just name it x.php instead of x.html. it's
> > designed with the coder in mind, not the code (which is why i say
> > an MS thing, they seem to be incapable of thinking any way but from
>
> > their own perspective)
> >
> >
> > reminds me of depreciating the <center> tag. what possible
> > improvement could you make by replacing it?! if it's off by a
> > pixel one in a thousand times, who cares?! (Web design just isn't
> > print design and CSS and XHTML are just blatantly dumb code
> > design) the tag is well worth it just because it works so clearly
> > and without memorizing. Design utility extends to a lot more than
> > just Italian coffee makers and German cars. Code is another
> > appliance.
> > +
> > -> post: [email protected]
> > -> questions: [email protected]
> > -> subscribe/unsubscribe: http://rhizome.org/preferences/
> > subscribe.rhiz
> > -> give: http://rhizome.org/support
> > +
> > Subscribers to Rhizome are subject to the terms set out in the
> > Membership Agreement available online at http://rhizome.org/info/
> > 29.php
> >
>
>
>
> –
> Pall Thayer
> [email protected]
> http://www.this.is/pallit
>
>
>
>

, MTAA

Yes, you are totally baffled.

You are confused btw code that is executed on the server-side (PHP,
Eric's Java code) and that which is executed on the client-side
(javascript, XHTML).

For example, AJAX techniques would allow someone to load the PHP
scripts you've been posting, read a the flat file and then write the
contents to a web page without re-loading that web page. The
HTTPrequest object is basically acting like a little browser within a
browser: it goes to the server, gets new info and returns it into a
javascript object. What most developers are using this for is to
create UIs for web applications that act more like UIs of desktop
applications – there isn't this whole send to server/wait/reload page
paradigm that has been the web til recently.

For example, Google maps. As you drag around the map the page is
constantly making requests to the server and getting the images you
need to build the map as you drag around. Go give it a try, you can
drag your ass all the way from San Fran to NYC – this wouldn't be
possible without using Ajax techniques because Google would need to
download an entire map of the US to your browser if they didn't want
to reload the page everytime you dragged off the current frame of
reference. With Ajax you just get the parts you request. This makes it
much more responsive.

On 2/5/06, Plasma Studii <[email protected]> wrote:
> for most of us, we're not dealing with thousands of pieces of info.
>
> it'd make sense for google to use a db, no need to read every map. there must be thousands. but why use Ajax to read em, when there are far more straight foreward ways? we don't have any use for the features Google needs, but if we really do want em, they they are easy to find.
>
>
> here's how to read the 3rd line (start from 0) only of a page. loads nothing.
>
>
> $Open = fopen("somePath/somePage.whatever", "r");
> if ($Open) {
> $Data = file ($Path);
> $Line3 = $Data[2];
> }
>
>
> am still baffled?????
>
>
>
>
> Pall Thayer wrote:
>
> > I think you're missing the point. It's not the ability to read or
> > write data to the server but the ability to do so in a way that
> > doesn't require reloading the entire page. Lets say person A in
> > Arkansas does something on the page that rewrites the data in your
> > anything.txt file. Person B in Botswana isn't going to see those
> > changes unless they reload the page. AJAX lets you do the reloading
> > in the background. Probably the best use of AJAX to this day, and
> > almost certainly a contributing factor to it's renewed rise to
> > stardom (it's been around for a while) is Google maps. It has
> > revolutionized the way maps are presented on the web. The interface
> > is absolutely brilliant and a huge leap away from the old method of
> > clicking on N, E, S or W to reload an image.
> >
> > Palli
> >
> > On 5.2.2006, at 10:09, Plasma Studii wrote:
> >
> > >> You will need to add the xmlrpc classes to your classpath, but
> > >> thats trivial.
> > >
> > >
> > > hey eric,
> > >
> > > probably, i'm just not getting this, but seems like the same result
> >
> > > would be SO much easier with PHP? PHP is super clear, whereas Ajax
> >
> > > just isn't at all. It's kinda the diff between intuitive and
> > > memorized. most folks don't even notice how much they memorize(as
> > > opposed to understand), but a lot seem like just arbitrary steps.
> > > sorta why reading/writing C is actually FAR more intuitively
> > > comprehensible (though compilers are usually convoluted) than
> > > anything in Flash.
> > >
> > > the steps to write to a file (any file on the web, not just XML) in
> >
> > > PHP are clear. seems it would be a lot more "available to
> > > artists"? is there some perk i'm missing here? Seems like
> > > bafflingly convoluted MS design?
> > >
> > >
> > >
> > >
> > > <?
> > >
> > > $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
> > to
> > > if ( $FileOpen ) {
> > > fwrite( $FileOpen, "write whatever you want, including HTML, XML
> > > or javascript code" );
> > > }
> > >
> > > ?>
> > >
> > >
> > > that's ALL the code it takes!
> > >
> > > upload it to a server running php (and about all of em do) this
> > > shows up on the page (or it's included with osX, a download, etc).
> >
> > > the code doesn't. if the page doesn't exist, it'll create it
> > > (though there's also a file_exists() function you can use if you
> > > don't want that to happen) the php could go absolutely anywhere on
> >
> > > your HTML page. just name it x.php instead of x.html. it's
> > > designed with the coder in mind, not the code (which is why i say
> > > an MS thing, they seem to be incapable of thinking any way but from
> >
> > > their own perspective)
> > >
> > >
> > > reminds me of depreciating the <center> tag. what possible
> > > improvement could you make by replacing it?! if it's off by a
> > > pixel one in a thousand times, who cares?! (Web design just isn't
> > > print design and CSS and XHTML are just blatantly dumb code
> > > design) the tag is well worth it just because it works so clearly
> > > and without memorizing. Design utility extends to a lot more than
> > > just Italian coffee makers and German cars. Code is another
> > > appliance.
> > > +
> > > -> post: [email protected]
> > > -> questions: [email protected]
> > > -> subscribe/unsubscribe: http://rhizome.org/preferences/
> > > subscribe.rhiz
> > > -> give: http://rhizome.org/support
> > > +
> > > Subscribers to Rhizome are subject to the terms set out in the
> > > Membership Agreement available online at http://rhizome.org/info/
> > > 29.php
> > >
> >
> >
> >
> > –
> > Pall Thayer
> > [email protected]
> > http://www.this.is/pallit
> >
> >
> >
> >
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/29.php
>



<twhid>www.mteww.com</twhid>

, Eric Dymond

Plasma Studii wrote:

> for most of us, we're not dealing with thousands of pieces of info.
>
> it'd make sense for google to use a db, no need to read every map.
> there must be thousands. but why use Ajax to read em, when there are
> far more straight foreward ways?

Well I think thats part of the point. XML has clear structure, going to an element is pretty easy compared to your method.
Paul's conceptual definition of AJAX is a good one. I can add that anywhere on the document can make callbacks, a mouseover a letter, a keystroke, just about any event you can images, changing the dynamic subtler ways than straightforward form/page processing.
Eric

, Pall Thayer

No. Once the page is at the clients end, PHP/Perl/whatever, isn't
doing anything.

On 5.2.2006, at 11:36, Plasma Studii wrote:

> you can do the very same thing with PHP (or Perl 10+ years ago).
> Ajax, Perl etc still read the whole page, but can be told to load
> only part of it?
>
>
>
>
> Pall Thayer wrote:
>
>> I think you're missing the point. It's not the ability to read or
>> write data to the server but the ability to do so in a way that
>> doesn't require reloading the entire page. Lets say person A in
>> Arkansas does something on the page that rewrites the data in your
>> anything.txt file. Person B in Botswana isn't going to see those
>> changes unless they reload the page. AJAX lets you do the reloading
>> in the background. Probably the best use of AJAX to this day, and
>> almost certainly a contributing factor to it's renewed rise to
>> stardom (it's been around for a while) is Google maps. It has
>> revolutionized the way maps are presented on the web. The interface
>> is absolutely brilliant and a huge leap away from the old method of
>> clicking on N, E, S or W to reload an image.
>>
>> Palli
>>
>> On 5.2.2006, at 10:09, Plasma Studii wrote:
>>
>>>> You will need to add the xmlrpc classes to your classpath, but
>>>> thats trivial.
>>>
>>>
>>> hey eric,
>>>
>>> probably, i'm just not getting this, but seems like the same result
>>
>>> would be SO much easier with PHP? PHP is super clear, whereas Ajax
>>
>>> just isn't at all. It's kinda the diff between intuitive and
>>> memorized. most folks don't even notice how much they memorize(as
>>> opposed to understand), but a lot seem like just arbitrary steps.
>>> sorta why reading/writing C is actually FAR more intuitively
>>> comprehensible (though compilers are usually convoluted) than
>>> anything in Flash.
>>>
>>> the steps to write to a file (any file on the web, not just XML) in
>>
>>> PHP are clear. seems it would be a lot more "available to
>>> artists"? is there some perk i'm missing here? Seems like
>>> bafflingly convoluted MS design?
>>>
>>>
>>>
>>>
>>> <?
>>>
>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
>> to
>>> if ( $FileOpen ) {
>>> fwrite( $FileOpen, "write whatever you want, including HTML, XML
>>> or javascript code" );
>>> }
>>>
>>> ?>
>>>
>>>
>>> that's ALL the code it takes!
>>>
>>> upload it to a server running php (and about all of em do) this
>>> shows up on the page (or it's included with osX, a download, etc).
>>
>>> the code doesn't. if the page doesn't exist, it'll create it
>>> (though there's also a file_exists() function you can use if you
>>> don't want that to happen) the php could go absolutely anywhere on
>>
>>> your HTML page. just name it x.php instead of x.html. it's
>>> designed with the coder in mind, not the code (which is why i say
>>> an MS thing, they seem to be incapable of thinking any way but from
>>
>>> their own perspective)
>>>
>>>
>>> reminds me of depreciating the <center> tag. what possible
>>> improvement could you make by replacing it?! if it's off by a
>>> pixel one in a thousand times, who cares?! (Web design just isn't
>>> print design and CSS and XHTML are just blatantly dumb code
>>> design) the tag is well worth it just because it works so clearly
>>> and without memorizing. Design utility extends to a lot more than
>>> just Italian coffee makers and German cars. Code is another
>>> appliance.
>>> +
>>> -> post: [email protected]
>>> -> questions: [email protected]
>>> -> subscribe/unsubscribe: http://rhizome.org/preferences/
>>> subscribe.rhiz
>>> -> give: http://rhizome.org/support
>>> +
>>> Subscribers to Rhizome are subject to the terms set out in the
>>> Membership Agreement available online at http://rhizome.org/info/
>>> 29.php
>>>
>>
>>
>>
>> –
>> Pall Thayer
>> [email protected]
>> http://www.this.is/pallit
>>
>>
>>
>>
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php
>




Pall Thayer
[email protected]
http://www.this.is/pallit

, Eric Dymond

> you can do the very same thing with PHP (or Perl 10+ years ago).
> Ajax, Perl etc still read the whole page, but can be told to load
> only part of it?
Yes. The area affected can be divs, spans, anything that we can set innerText or innerHTML to. If it's got an id, then it can be posted to. The rest of the page remains intact.
Eric

, Plasma Studii

true. but why is that particularly important. either way, the client pushes a button and gets a result. if that result is processed on the server or on their machine, there isn't much difference to them. most users would never know, and certainly none would ever care, if there's no benefit other than client side/server side in and of itself.

which is pretty much my point. client-side technology is generally viewed as being more accessible, but really it's mostly hype. quite often no significant improvement or simplification over server-side.


Pall Thayer wrote:

> No. Once the page is at the clients end, PHP/Perl/whatever, isn't
> doing anything.
>
> On 5.2.2006, at 11:36, Plasma Studii wrote:
>
> > you can do the very same thing with PHP (or Perl 10+ years ago).
> > Ajax, Perl etc still read the whole page, but can be told to load
> > only part of it?
> >
> >
> >
> >
> > Pall Thayer wrote:
> >
> >> I think you're missing the point. It's not the ability to read or
> >> write data to the server but the ability to do so in a way that
> >> doesn't require reloading the entire page. Lets say person A in
> >> Arkansas does something on the page that rewrites the data in your
> >> anything.txt file. Person B in Botswana isn't going to see those
> >> changes unless they reload the page. AJAX lets you do the reloading
> >> in the background. Probably the best use of AJAX to this day, and
> >> almost certainly a contributing factor to it's renewed rise to
> >> stardom (it's been around for a while) is Google maps. It has
> >> revolutionized the way maps are presented on the web. The interface
> >> is absolutely brilliant and a huge leap away from the old method of
> >> clicking on N, E, S or W to reload an image.
> >>
> >> Palli
> >>
> >> On 5.2.2006, at 10:09, Plasma Studii wrote:
> >>
> >>>> You will need to add the xmlrpc classes to your classpath, but
> >>>> thats trivial.
> >>>
> >>>
> >>> hey eric,
> >>>
> >>> probably, i'm just not getting this, but seems like the same
> result
> >>
> >>> would be SO much easier with PHP? PHP is super clear, whereas
> Ajax
> >>
> >>> just isn't at all. It's kinda the diff between intuitive and
> >>> memorized. most folks don't even notice how much they memorize(as
> >>> opposed to understand), but a lot seem like just arbitrary steps.
> >>> sorta why reading/writing C is actually FAR more intuitively
> >>> comprehensible (though compilers are usually convoluted) than
> >>> anything in Flash.
> >>>
> >>> the steps to write to a file (any file on the web, not just XML)
> in
> >>
> >>> PHP are clear. seems it would be a lot more "available to
> >>> artists"? is there some perk i'm missing here? Seems like
> >>> bafflingly convoluted MS design?
> >>>
> >>>
> >>>
> >>>
> >>> <?
> >>>
> >>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
> >> to
> >>> if ( $FileOpen ) {
> >>> fwrite( $FileOpen, "write whatever you want, including HTML, XML
> >>> or javascript code" );
> >>> }
> >>>
> >>> ?>
> >>>
> >>>
> >>> that's ALL the code it takes!
> >>>
> >>> upload it to a server running php (and about all of em do) this
> >>> shows up on the page (or it's included with osX, a download, etc).
> >>
> >>> the code doesn't. if the page doesn't exist, it'll create it
> >>> (though there's also a file_exists() function you can use if you
> >>> don't want that to happen) the php could go absolutely anywhere
> on
> >>
> >>> your HTML page. just name it x.php instead of x.html. it's
> >>> designed with the coder in mind, not the code (which is why i say
> >>> an MS thing, they seem to be incapable of thinking any way but
> from
> >>
> >>> their own perspective)
> >>>
> >>>
> >>> reminds me of depreciating the <center> tag. what possible
> >>> improvement could you make by replacing it?! if it's off by a
> >>> pixel one in a thousand times, who cares?! (Web design just isn't
> >>> print design and CSS and XHTML are just blatantly dumb code
> >>> design) the tag is well worth it just because it works so clearly
> >>> and without memorizing. Design utility extends to a lot more than
> >>> just Italian coffee makers and German cars. Code is another
> >>> appliance.
> >>> +
> >>> -> post: [email protected]
> >>> -> questions: [email protected]
> >>> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> >>> subscribe.rhiz
> >>> -> give: http://rhizome.org/support
> >>> +
> >>> Subscribers to Rhizome are subject to the terms set out in the
> >>> Membership Agreement available online at http://rhizome.org/info/
> >>> 29.php
> >>>
> >>
> >>
> >>
> >> –
> >> Pall Thayer
> >> [email protected]
> >> http://www.this.is/pallit
> >>
> >>
> >>
> >>
> > +
> > -> post: [email protected]
> > -> questions: [email protected]
> > -> subscribe/unsubscribe: http://rhizome.org/preferences/
> > subscribe.rhiz
> > -> give: http://rhizome.org/support
> > +
> > Subscribers to Rhizome are subject to the terms set out in the
> > Membership Agreement available online at http://rhizome.org/info/
> > 29.php
> >
>
>
>
> –
> Pall Thayer
> [email protected]
> http://www.this.is/pallit
>
>
>
>

, Rob Myers

On 5 Feb 2006, at 18:45, Plasma Studii wrote:

> which is pretty much my point. client-side technology is generally
> viewed as being more accessible, but really it's mostly hype.
> quite often no significant improvement or simplification over
> server-side.

AJAX is hype, but refreshing or adding content without a page refresh
and without plugin is a genuine advance.

- Rob

, Pall Thayer

It's not necessarily about 'new' functionality per se. It's more
about the user experience. It's about dynamic content in a seamless
and invisible way. It's only what you need when you need it. When you
get a table containing 500 elements, you don't need elements 200 to
300 till you scroll down. Of course, we could display the first 100
elements and then at the bottom of the page is a 'next' link that
takes you to the next 100. But let's say I'm on page 3 and I want to
go back and see item 78. The old way, I go to the bottom of the page
and click on previous, and again, and then locate 78. With AJAX, I
simply scroll back up (using two fingers on my trackpad, which
incidentally isn't 'new' functionality either, just a better, more
intuitive user experience. If you haven't tried it, it's better than
it sounds). Try comparing google maps and mapquest and tell us which
one "feels" better.

Pall

On 5.2.2006, at 15:12, judson wrote:

> true. but why is that particularly important. either way, the
> client pushes a button and gets a result. if that result is
> processed on the server or on their machine, there isn't much
> difference to them. most users would never know, and certainly
> none would ever care, if there's no benefit other than client side/
> server side in and of itself.
>
> which is pretty much my point. client-side technology is generally
> viewed as being more accessible, but really it's mostly hype, and
> often no significant improvement or simplification over server-side.
>
>
> On Feb 5, 2006, at 12:36 PM, Pall Thayer wrote:
>
>> No. Once the page is at the clients end, PHP/Perl/whatever, isn't
>> doing anything.
>>
>> On 5.2.2006, at 11:36, Plasma Studii wrote:
>>
>>> you can do the very same thing with PHP (or Perl 10+ years ago).
>>> Ajax, Perl etc still read the whole page, but can be told to load
>>> only part of it?
>>>
>>>
>>>
>>>
>>> Pall Thayer wrote:
>>>
>>>> I think you're missing the point. It's not the ability to read or
>>>> write data to the server but the ability to do so in a way that
>>>> doesn't require reloading the entire page. Lets say person A in
>>>> Arkansas does something on the page that rewrites the data in your
>>>> anything.txt file. Person B in Botswana isn't going to see those
>>>> changes unless they reload the page. AJAX lets you do the reloading
>>>> in the background. Probably the best use of AJAX to this day, and
>>>> almost certainly a contributing factor to it's renewed rise to
>>>> stardom (it's been around for a while) is Google maps. It has
>>>> revolutionized the way maps are presented on the web. The interface
>>>> is absolutely brilliant and a huge leap away from the old method of
>>>> clicking on N, E, S or W to reload an image.
>>>>
>>>> Palli
>>>>
>>>> On 5.2.2006, at 10:09, Plasma Studii wrote:
>>>>
>>>>>> You will need to add the xmlrpc classes to your classpath, but
>>>>>> thats trivial.
>>>>>
>>>>>
>>>>> hey eric,
>>>>>
>>>>> probably, i'm just not getting this, but seems like the same
>>>>> result
>>>>
>>>>> would be SO much easier with PHP? PHP is super clear, whereas
>>>>> Ajax
>>>>
>>>>> just isn't at all. It's kinda the diff between intuitive and
>>>>> memorized. most folks don't even notice how much they memorize(as
>>>>> opposed to understand), but a lot seem like just arbitrary steps.
>>>>> sorta why reading/writing C is actually FAR more intuitively
>>>>> comprehensible (though compilers are usually convoluted) than
>>>>> anything in Flash.
>>>>>
>>>>> the steps to write to a file (any file on the web, not just
>>>>> XML) in
>>>>
>>>>> PHP are clear. seems it would be a lot more "available to
>>>>> artists"? is there some perk i'm missing here? Seems like
>>>>> bafflingly convoluted MS design?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <?
>>>>>
>>>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write
>>>> to
>>>>> if ( $FileOpen ) {
>>>>> fwrite( $FileOpen, "write whatever you want, including HTML, XML
>>>>> or javascript code" );
>>>>> }
>>>>>
>>>>> ?>
>>>>>
>>>>>
>>>>> that's ALL the code it takes!
>>>>>
>>>>> upload it to a server running php (and about all of em do) this
>>>>> shows up on the page (or it's included with osX, a download, etc).
>>>>
>>>>> the code doesn't. if the page doesn't exist, it'll create it
>>>>> (though there's also a file_exists() function you can use if you
>>>>> don't want that to happen) the php could go absolutely
>>>>> anywhere on
>>>>
>>>>> your HTML page. just name it x.php instead of x.html. it's
>>>>> designed with the coder in mind, not the code (which is why i say
>>>>> an MS thing, they seem to be incapable of thinking any way but
>>>>> from
>>>>
>>>>> their own perspective)
>>>>>
>>>>>
>>>>> reminds me of depreciating the <center> tag. what possible
>>>>> improvement could you make by replacing it?! if it's off by a
>>>>> pixel one in a thousand times, who cares?! (Web design just isn't
>>>>> print design and CSS and XHTML are just blatantly dumb code
>>>>> design) the tag is well worth it just because it works so clearly
>>>>> and without memorizing. Design utility extends to a lot more than
>>>>> just Italian coffee makers and German cars. Code is another
>>>>> appliance.
>>>>> +
>>>>> -> post: [email protected]
>>>>> -> questions: [email protected]
>>>>> -> subscribe/unsubscribe: http://rhizome.org/preferences/
>>>>> subscribe.rhiz
>>>>> -> give: http://rhizome.org/support
>>>>> +
>>>>> Subscribers to Rhizome are subject to the terms set out in the
>>>>> Membership Agreement available online at http://rhizome.org/info/
>>>>> 29.php
>>>>>
>>>>
>>>>
>>>>
>>>> –
>>>> Pall Thayer
>>>> [email protected]
>>>> http://www.this.is/pallit
>>>>
>>>>
>>>>
>>>>
>>> +
>>> -> post: [email protected]
>>> -> questions: [email protected]
>>> -> subscribe/unsubscribe: http://rhizome.org/preferences/
>>> subscribe.rhiz
>>> -> give: http://rhizome.org/support
>>> +
>>> Subscribers to Rhizome are subject to the terms set out in the
>>> Membership Agreement available online at http://rhizome.org/info/
>>> 29.php
>>>
>>
>>
>>
>> –
>> Pall Thayer
>> [email protected]
>> http://www.this.is/pallit
>>
>>
>>
>>
>>
>




Pall Thayer
[email protected]
http://www.this.is/pallit

, Jason Van Anden

Programmers tend to be skeptical of trendy new technologies,especially after having invested so much time becoming expert in oneonly to be told it's become obsolete. I suspect thatartist/programmers even more so, in that we want to quickly create thethings we imagine, and the overhead of coding often requires an bigdown payment.
I think this is the reason that Eric is emphasising the importance ofthis particular technology (and also why some seem so hesitant).
There are many ways to do what AJAX does - and in that sense it isn'tnew. Some of the reasons its so cool is:
1.) its neat (clean, easy, elegant, efficient, etc…). It humanreadability makes it a joy to code.
2.) it has community support (unlike SOAP which I think did notcapture the hearts of programmers because of its MS-centric syntax).Assuming code/knowledge is being shared, this eliminates some of theoverhead mentioned above.
3.) it can drastically improve the user experience. At this point itworks on most any browser so its easy to use and it allows for a moreefficient use of bandwidth since it can significantly reduce thenumber of round trips and amount of data being passed between theclient and server.
Fellow programmers, write this down, AJAX rocks, learn it an you willnot be sorry.
More about it here:http://www.adaptivepath.com/publications/essays/archives/000385.php
A very simple example of AJAX can be seen in my first foray into artwith a political agenda called "Tax the Rich!" (link below). As faras I can tell its the only "net art" piece of the bunch, but I'mafraid this is not a compelling enough reason for people to view itover some of the sillier entries.
http://tax.cf.huffingtonpost.com
Jason Van Anden


On 2/5/06, Pall Thayer <[email protected]> wrote:> It's not necessarily about 'new' functionality per se. It's more> about the user experience. It's about dynamic content in a seamless> and invisible way. It's only what you need when you need it. When you> get a table containing 500 elements, you don't need elements 200 to> 300 till you scroll down. Of course, we could display the first 100> elements and then at the bottom of the page is a 'next' link that> takes you to the next 100. But let's say I'm on page 3 and I want to> go back and see item 78. The old way, I go to the bottom of the page> and click on previous, and again, and then locate 78. With AJAX, I> simply scroll back up (using two fingers on my trackpad, which> incidentally isn't 'new' functionality either, just a better, more> intuitive user experience. If you haven't tried it, it's better than> it sounds). Try comparing google maps and mapquest and tell us which> one "feels" better.>> Pall>> On 5.2.2006, at 15:12, judson wrote:>> > true. but why is that particularly important. either way, the> > client pushes a button and gets a result. if that result is> > processed on the server or on their machine, there isn't much> > difference to them. most users would never know, and certainly> > none would ever care, if there's no benefit other than client side/> > server side in and of itself.> >> > which is pretty much my point. client-side technology is generally> > viewed as being more accessible, but really it's mostly hype, and> > often no significant improvement or simplification over server-side.> >> >> > On Feb 5, 2006, at 12:36 PM, Pall Thayer wrote:> >> >> No. Once the page is at the clients end, PHP/Perl/whatever, isn't> >> doing anything.> >>> >> On 5.2.2006, at 11:36, Plasma Studii wrote:> >>> >>> you can do the very same thing with PHP (or Perl 10+ years ago).> >>> Ajax, Perl etc still read the whole page, but can be told to load> >>> only part of it?> >>>> >>>> >>>> >>>> >>> Pall Thayer wrote:> >>>> >>>> I think you're missing the point. It's not the ability to read or> >>>> write data to the server but the ability to do so in a way that> >>>> doesn't require reloading the entire page. Lets say person A in> >>>> Arkansas does something on the page that rewrites the data in your> >>>> anything.txt file. Person B in Botswana isn't going to see those> >>>> changes unless they reload the page. AJAX lets you do the reloading> >>>> in the background. Probably the best use of AJAX to this day, and> >>>> almost certainly a contributing factor to it's renewed rise to> >>>> stardom (it's been around for a while) is Google maps. It has> >>>> revolutionized the way maps are presented on the web. The interface> >>>> is absolutely brilliant and a huge leap away from the old method of> >>>> clicking on N, E, S or W to reload an image.> >>>>> >>>> Palli> >>>>> >>>> On 5.2.2006, at 10:09, Plasma Studii wrote:> >>>>> >>>>>> You will need to add the xmlrpc classes to your classpath, but> >>>>>> thats trivial.> >>>>>> >>>>>> >>>>> hey eric,> >>>>>> >>>>> probably, i'm just not getting this, but seems like the same> >>>>> result> >>>>> >>>>> would be SO much easier with PHP? PHP is super clear, whereas> >>>>> Ajax> >>>>> >>>>> just isn't at all. It's kinda the diff between intuitive and> >>>>> memorized. most folks don't even notice how much they memorize(as> >>>>> opposed to understand), but a lot seem like just arbitrary steps.> >>>>> sorta why reading/writing C is actually FAR more intuitively> >>>>> comprehensible (though compilers are usually convoluted) than> >>>>> anything in Flash.> >>>>>> >>>>> the steps to write to a file (any file on the web, not just> >>>>> XML) in> >>>>> >>>>> PHP are clear. seems it would be a lot more "available to> >>>>> artists"? is there some perk i'm missing here? Seems like> >>>>> bafflingly convoluted MS design?> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> <?> >>>>>> >>>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write> >>>> to> >>>>> if ( $FileOpen ) {> >>>>> fwrite( $FileOpen, "write whatever you want, including HTML, XML> >>>>> or javascript code" );> >>>>> }> >>>>>> >>>>> ?>> >>>>>> >>>>>> >>>>> that's ALL the code it takes!> >>>>>> >>>>> upload it to a server running php (and about all of em do) this> >>>>> shows up on the page (or it's included with osX, a download, etc).> >>>>> >>>>> the code doesn't. if the page doesn't exist, it'll create it> >>>>> (though there's also a file_exists() function you can use if you> >>>>> don't want that to happen) the php could go absolutely> >>>>> anywhere on> >>>>> >>>>> your HTML page. just name it x.php instead of x.html. it's> >>>>> designed with the coder in mind, not the code (which is why i say> >>>>> an MS thing, they seem to be incapable of thinking any way but> >>>>> from> >>>>> >>>>> their own perspective)> >>>>>> >>>>>> >>>>> reminds me of depreciating the <center> tag. what possible> >>>>> improvement could you make by replacing it?! if it's off by a> >>>>> pixel one in a thousand times, who cares?! (Web design just isn't> >>>>> print design and CSS and XHTML are just blatantly dumb code> >>>>> design) the tag is well worth it just because it works so clearly> >>>>> and without memorizing. Design utility extends to a lot more than> >>>>> just Italian coffee makers and German cars. Code is another> >>>>> appliance.> >>>>> +> >>>>> -> post: [email protected]> >>>>> -> questions: [email protected]> >>>>> -> subscribe/unsubscribe: http://rhizome.org/preferences/> >>>>> subscribe.rhiz> >>>>> -> give: http://rhizome.org/support> >>>>> +> >>>>> Subscribers to Rhizome are subject to the terms set out in the> >>>>> Membership Agreement available online at http://rhizome.org/info/> >>>>> 29.php> >>>>>> >>>>> >>>>> >>>>> >>>> –> >>>> Pall Thayer> >>>> [email protected]> >>>> http://www.this.is/pallit> >>>>> >>>>> >>>>> >>>>> >>> +> >>> -> post: [email protected]> >>> -> questions: [email protected]> >>> -> subscribe/unsubscribe: http://rhizome.org/preferences/> >>> subscribe.rhiz> >>> -> give: http://rhizome.org/support> >>> +> >>> Subscribers to Rhizome are subject to the terms set out in the> >>> Membership Agreement available online at http://rhizome.org/info/> >>> 29.php> >>>> >>> >>> >>> >> –> >> Pall Thayer> >> [email protected]> >> http://www.this.is/pallit> >>> >>> >>> >>> >>> >>>>> –> Pall Thayer> [email protected]> http://www.this.is/pallit>>>>> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>

–Jason Van Andenhttp://www.smileproject.com

, Lewis LaCook

well, once we start using a protocol more suited to network transmissions as networks are NOW all of this will be moot–>

lol









Jason Van Anden <[email protected]> wrote:Programmers tend to be skeptical of trendy new technologies,especially after having invested so much time becoming expert in oneonly to be told it's become obsolete. I suspect thatartist/programmers even more so, in that we want to quickly create thethings we imagine, and the overhead of coding often requires an bigdown payment.
I think this is the reason that Eric is emphasising the importance ofthis particular technology (and also why some seem so hesitant).
There are many ways to do what AJAX does - and in that sense it isn'tnew. Some of the reasons its so cool is:
1.) its neat (clean, easy, elegant, efficient, etc…). It humanreadability makes it a joy to code.
2.) it has community support (unlike SOAP which I think did notcapture the hearts of programmers because of its MS-centric syntax).Assuming code/knowledge is being shared, this eliminates some of theoverhead mentioned above.
3.) it can drastically improve the user experience. At this point itworks on most any browser so its easy to use and it allows for a moreefficient use of bandwidth since it can significantly reduce thenumber of round trips and amount of data being passed between theclient and server.
Fellow programmers, write this down, AJAX rocks, learn it an you willnot be sorry.
More about it here:http://www.adaptivepath.com/publications/essays/archives/000385.php
A very simple example of AJAX can be seen in my first foray into artwith a political agenda called "Tax the Rich!" (link below). As faras I can tell its the only "net art" piece of the bunch, but I'mafraid this is not a compelling enough reason for people to view itover some of the sillier entries.
http://tax.cf.huffingtonpost.com
Jason Van Anden


On 2/5/06, Pall Thayer
wrote:> It's not necessarily about 'new' functionality per se. It's more> about the user experience. It's about dynamic content in a seamless> and invisible way. It's only what you need when you need it. When you> get a table containing 500 elements, you don't need elements 200 to> 300 till you scroll down. Of course, we could display the first 100> elements and then at the bottom of the page is a 'next' link that> takes you to the next 100. But let's say I'm on page 3 and I want to> go back and see item 78. The old way, I go to the bottom of the page> and click on previous, and again, and then locate 78. With AJAX, I> simply scroll back up (using two fingers on my trackpad, which> incidentally isn't 'new' functionality either, just a better, more> intuitive user experience. If you haven't tried it, it's better than> it sounds). Try comparing google maps and mapquest and tell us which> one "feels" better.>> Pall>> On 5.2.200!
6, at 15:12, judson wrote:>> > true. but why is that particularly important. either way, the> > client pushes a button and gets a result. if that result is> > processed on the server or on their machine, there isn't much> > difference to them. most users would never know, and certainly> > none would ever care, if there's no benefit other than client side/> > server side in and of itself.> >> > which is pretty much my point. client-side technology is generally> > viewed as being more accessible, but really it's mostly hype, and> > often no significant improvement or simplification over server-side.> >> >> > On Feb 5, 2006, at 12:36 PM, Pall Thayer wrote:> >> >> No. Once the page is at the clients end, PHP/Perl/whatever, isn't> >> doing anything.> >>> >> On 5.2.2006, at 11:36, Plasma Studii wrote:> >>> >>> you can do the very same thing with PHP (or Perl 10+ years ago).> >>> Ajax, Perl etc still read the whole page, but can be told to load> >>> only part of it?> >>>>
>>>>!
>>>> >>>> >>> Pall Thayer wrote:> >>>> >>>> I think you're m!
issing t
he point. It's not the ability to read or> >>>> write data to the server but the ability to do so in a way that> >>>> doesn't require reloading the entire page. Lets say person A in> >>>> Arkansas does something on the page that rewrites the data in your> >>>> anything.txt file. Person B in Botswana isn't going to see those> >>>> changes unless they reload the page. AJAX lets you do the reloading> >>>> in the background. Probably the best use of AJAX to this day, and> >>>> almost certainly a contributing factor to it's renewed rise to> >>>> stardom (it's been around for a while) is Google maps. It has> >>>> revolutionized the way maps are presented on the web. The interface> >>>> is absolutely brilliant and a huge leap away from the old method of> >>>> clicking on N, E, S or W to reload an image.> >>>>> >>>> Palli> >>>>> >>>> On 5.2.2006, at 10:09, Plasma Studii wrote:> >>>>> >>>>>> You will need to add the xmlrpc classes to your classpath, but> >>>>>> thats
trivial.> >>>>>>!
>>>>>> >>>>> hey eric,> >>>>>> >>>>> probably, i'm just not getting this, but seems like the same> >>>>> result> >>>>> >>>>> would be SO much easier with PHP? PHP is super clear, whereas> >>>>> Ajax> >>>>> >>>>> just isn't at all. It's kinda the diff between intuitive and> >>>>> memorized. most folks don't even notice how much they memorize(as> >>>>> opposed to understand), but a lot seem like just arbitrary steps.> >>>>> sorta why reading/writing C is actually FAR more intuitively> >>>>> comprehensible (though compilers are usually convoluted) than> >>>>> anything in Flash.> >>>>>> >>>>> the steps to write to a file (any file on the web, not just> >>>>> XML) in> >>>>> >>>>> PHP are clear. seems it would be a lot more "available to> >>>>> artists"? is there some perk i'm missing here? Seems like> >>>>> bafflingly convoluted MS design?> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write> >>>> to>
>>>>>!
if ( $FileOpen ) {> >>>>> fwrite( $FileOpen, "write whateve!
r you wa
nt, including HTML, XML> >>>>> or javascript code" );> >>>>> }> >>>>>> >>>>> ?>> >>>>>> >>>>>> >>>>> that's ALL the code it takes!> >>>>>> >>>>> upload it to a server running php (and about all of em do) this> >>>>> shows up on the page (or it's included with osX, a download, etc).> >>>>> >>>>> the code doesn't. if the page doesn't exist, it'll create it> >>>>> (though there's also a file_exists() function you can use if you> >>>>> don't want that to happen) the php could go absolutely> >>>>> anywhere on> >>>>> >>>>> your HTML page. just name it x.php instead of x.html. it's> >>>>> designed with the coder in mind, not the code (which is why i say> >>>>> an MS thing, they seem to be incapable of thinking any way but> >>>>> from> >>>>> >>>>> their own perspective)> >>>>>> >>>>>> >>>>> reminds me of depreciating the
tag. what possible> >>>>> improvement could you make by replacing it?! if it's off by a> >>>>> pixel one in a thousand times, who cares?! (Web desig!
n just isn't> >>>>> print design and CSS and XHTML are just blatantly dumb code> >>>>> design) the tag is well worth it just because it works so clearly> >>>>> and without memorizing. Design utility extends to a lot more than> >>>>> just Italian coffee makers and German cars. Code is another> >>>>> appliance.> >>>>> +> >>>>> -> post: [email protected]> >>>>> -> questions: [email protected]> >>>>> -> subscribe/unsubscribe: http://rhizome.org/preferences/> >>>>> subscribe.rhiz> >>>>> -> give: http://rhizome.org/support> >>>>> +> >>>>> Subscribers to Rhizome are subject to the terms set out in the> >>>>> Membership Agreement available online at http://rhizome.org/info/> >>>>> 29.php> >>>>>> >>>>> >>>>> >>>>> >>>> –> >>>> Pall Thayer> >>>> [email protected]> >>>> http://www.this.is/pallit> >>>>> >>>>> >>>>> >>>>> >>> +> >>> -> post: [email protected]> >>> -> questions: [email protected]> >>> -> subscribe/unsubscribe: http://rhizome.org/preferences/> >>>
subscribe.rhiz> !
>>> -> give: http://rhizome.org/support> >>> +> >>> Subscriber!
s to Rhi
zome are subject to the terms set out in the> >>> Membership Agreement available online at http://rhizome.org/info/> >>> 29.php> >>>> >>> >>> >>> >> –> >> Pall Thayer> >> [email protected]> >> http://www.this.is/pallit> >>> >>> >>> >>> >>> >>>>> –> Pall Thayer> [email protected]> http://www.this.is/pallit>>>>> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>

–Jason Van Andenhttp://www.smileproject.com
+
-> post: [email protected]
-> questions: [email protected]
-> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz
-> give: http://rhizome.org/support
+
Subscribers to Rhizome are subject to the terms set out in the
Membership Agreement available online at http://rhizome.org/info/29.php



***************************************************************************

||http://www.lewislacook.org||
sign up now! poetry, code, forums, blogs, newsfeeds…




———————————

What are the most popular cars? Find out at Yahoo! Autos

, Jason Van Anden

Lewis - how so?
(super weird gmail garbling of my last post -ack!)
Jason


On 2/6/06, Lewis LaCook <[email protected]> wrote:> well, once we start using a protocol more suited to network transmissions as> networks are NOW all of this will be moot–>>> lol>>>>>>>>>> Jason Van Anden <[email protected]> wrote:> Programmers tend to be skeptical of trendy new technologies,especially after> having invested so much time becoming expert in oneonly to be told it's> become obsolete. I suspect thatartist/programmers even more so, in that we> want to quickly create thethings we imagine, and the overhead of coding> often requires an bigdown payment.> I think this is the reason that Eric is emphasising the importance ofthis> particular technology (and also why some seem so hesitant).> There are many ways to do what AJAX does - and in that sense it isn'tnew.> Some of the reasons its so cool is:> 1.) its neat (clean, easy, elegant, efficient, etc…). It humanreadability> makes it a joy to code.> 2.) it has community support (unlike SOAP which I think did notcapture the> hearts of programmers because of its MS-centric syntax).Assuming> code/knowledge is being shared, this eliminates some of theoverhead> mentioned above.> 3.) it can drastically improve the user experience. At this point itworks on> most any browser so its easy to use and it allows for a moreefficient use of> bandwidth since it can significantly reduce thenumber of round trips and> amount of data being passed between theclient and server.> Fellow programmers, write this down, AJAX rocks, learn it an you willnot be> sorry.> More about it> here:http://www.adaptivepath.com/publications/essays/archives/000385.php> A very simple example of AJAX can be seen in my first foray into artwith a> political agenda called "Tax the Rich!" (link below). As faras I can tell> its the only "net art" piece of the bunch, but I'mafraid this is not a> compelling enough reason for people to view itover some of the sillier> entries.> http://tax.cf.huffingtonpost.com> Jason Van Anden>>> On 2/5/06, Pall Thayer>> wrote:> It's not necessarily about 'new' functionality per se. It's more>> about the user experience. It's about dynamic content in a seamless> and> invisible way. It's only what you need when you need it. When you> get a> table containing 500 elements, you don't need elements 200 to> 300 till you> scroll down. Of course, we could display the first 100> elements and then at> the bottom of the page is a 'next' link that> takes you to the next 100. But> let's say I'm on page 3 and I want to> go back and see item 78. The old way,> I go to the bottom of the page> and click on previous, and again, and then> locate 78. With AJAX, I> simply scroll back up (using two fingers on my> trackpad, which> incidentally isn't 'new' functionality either, just a> better, more> intuitive user experience. If you haven't tried it, it's> better than> it sounds). Try comparing google maps and mapquest and tell us> which> one "feels" better.>> Pall>> On 5.2.200!> 6, at 15:12, judson wrote:>> > true. but why is that particularly> important. either way, the> > client pushes a button and gets a result. if> that result is> > processed on the server or on their machine, there isn't> much> > difference to them. most users would never know, and certainly> >> none would ever care, if there's no benefit other than client side/> >> server side in and of itself.> >> > which is pretty much my point.> client-side technology is generally> > viewed as being more accessible, but> really it's mostly hype, and> > often no significant improvement or> simplification over server-side.> >> >> > On Feb 5, 2006, at 12:36 PM, Pall> Thayer wrote:> >> >> No. Once the page is at the clients end,> PHP/Perl/whatever, isn't> >> doing anything.> >>> >> On 5.2.2006, at 11:36,> Plasma Studii wrote:> >>> >>> you can do the very same thing with PHP (or> Perl 10+ years ago).> >>> Ajax, Perl etc still read the whole page, but can> be told to load> >>> only part of it?> >>>> >>>>!> >>>> >>>> >>> Pall Thayer wrote:> >>>> >>>> I think you're m!> issing t> he point. It's not the ability to read or> >>>> write data to the server but> the ability to do so in a way that> >>>> doesn't require reloading the> entire page. Lets say person A in> >>>> Arkansas does something on the page> that rewrites the data in your> >>>> anything.txt file. Person B in Botswana> isn't going to see those> >>>> changes unless they reload the page. AJAX> lets you do the reloading> >>>> in the background. Probably the best use of> AJAX to this day, and> >>>> almost certainly a contributing factor to it's> renewed rise to> >>>> stardom (it's been around for a while) is Google maps.> It has> >>>> revolutionized the way maps are presented on the web. The> interface> >>>> is absolutely brilliant and a huge leap away from the old> method of> >>>> clicking on N, E, S or W to reload an image.> >>>>> >>>>> Palli> >>>>> >>>> On 5.2.2006, at 10:09, Plasma Studii wrote:> >>>>> >>>>>>> You will need to add the xmlrpc classes to your classpath, but> >>>>>> thats> trivial.> >>>>>>!> >>>>>> >>>>> hey eric,> >>>>>> >>>>> probably, i'm just not getting this,> but seems like the same> >>>>> result> >>>>> >>>>> would be SO much easier> with PHP? PHP is super clear, whereas> >>>>> Ajax> >>>>> >>>>> just isn't at> all. It's kinda the diff between intuitive and> >>>>> memorized. most folks> don't even notice how much they memorize(as> >>>>> opposed to understand),> but a lot seem like just arbitrary steps.> >>>>> sorta why reading/writing C> is actually FAR more intuitively> >>>>> comprehensible (though compilers are> usually convoluted) than> >>>>> anything in Flash.> >>>>>> >>>>> the steps> to write to a file (any file on the web, not just> >>>>> XML) in> >>>>>> >>>>> PHP are clear. seems it would be a lot more "available to> >>>>>> artists"? is there some perk i'm missing here? Seems like> >>>>> bafflingly> convoluted MS design?> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write> >>>> to>> >>>>>!> if ( $FileOpen ) {> >>>>> fwrite( $FileOpen, "write whateve!> r you wa> nt, including HTML, XML> >>>>> or javascript code" );> >>>>> }> >>>>>> >>>>>> ?>> >>>>>> >>>>>> >>>>> that's ALL the code it takes!> >>>>>> >>>>> upload> it to a server running php (and about all of em do) this> >>>>> shows up on> the page (or it's included with osX, a download, etc).> >>>>> >>>>> the code> doesn't. if the page doesn't exist, it'll create it> >>>>> (though there's> also a file_exists() function you can use if you> >>>>> don't want that to> happen) the php could go absolutely> >>>>> anywhere on> >>>>> >>>>> your> HTML page. just name it x.php instead of x.html. it's> >>>>> designed with> the coder in mind, not the code (which is why i say> >>>>> an MS thing, they> seem to be incapable of thinking any way but> >>>>> from> >>>>> >>>>> their> own perspective)> >>>>>> >>>>>> >>>>> reminds me of depreciating the tag.> what possible> >>>>> improvement could you make by replacing it?! if it's> off by a> >>>>> pixel one in a thousand times, who cares?! (Web desig!> n just isn't> >>>>> print design and CSS and XHTML are just blatantly dumb> code> >>>>> design) the tag is well worth it just because it works so> clearly> >>>>> and without memorizing. Design utility extends to a lot more> than> >>>>> just Italian coffee makers and German cars. Code is another>> >>>>> appliance.> >>>>> +> >>>>> -> post: [email protected]> >>>>> ->> questions: [email protected]> >>>>> -> subscribe/unsubscribe:> http://rhizome.org/preferences/> >>>>> subscribe.rhiz> >>>>> -> give:> http://rhizome.org/support> >>>>> +> >>>>> Subscribers to Rhizome are> subject to the terms set out in the> >>>>> Membership Agreement available> online at http://rhizome.org/info/> >>>>> 29.php> >>>>>> >>>>> >>>>> >>>>>> >>>> –> >>>> Pall Thayer> >>>> [email protected]> >>>>> http://www.this.is/pallit> >>>>> >>>>> >>>>> >>>>> >>> +> >>> -> post:> [email protected]> >>> -> questions: [email protected]> >>> ->> subscribe/unsubscribe: http://rhizome.org/preferences/> >>> subscribe.rhiz>> !> >>> -> give: http://rhizome.org/support> >>> +> >>> Subscriber!> s to Rhi> zome are subject to the terms set out in the> >>> Membership Agreement> available online at http://rhizome.org/info/> >>> 29.php> >>>> >>> >>> >>>> >> –> >> Pall Thayer> >> [email protected]> >>> http://www.this.is/pallit> >>> >>> >>> >>> >>> >>>>> –> Pall Thayer>> [email protected]> http://www.this.is/pallit>>>>> +> -> post:> [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe:> http://rhizome.org/preferences/subscribe.rhiz> -> give:> http://rhizome.org/support> +> Subscribers to Rhizome are subject to the> terms set out in the> Membership Agreement available online at> http://rhizome.org/info/29.php>>> –Jason Van Andenhttp://www.smileproject.com> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe:> http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>>>> ***************************************************************************>>> ||http://www.lewislacook.org||> sign up now! poetry, code, forums, blogs, newsfeeds…>>> ________________________________>> What are the most popular cars? Find out at Yahoo! Autos>>

–Jason Van Andenhttp://www.smileproject.com

, Plasma Studii

ha ha. "to Ajax or not to Ajax" will probably be a moot point in a few years anyway. that's really not my question though. no, i don't mind obsoletism. though higher end tech, rarely becomes obsolete. C was around before most of us were born. Perl was probably around before the net. Java has existed since it was created. PHP is relatively new, but i do hope it survives (not because i can't learn a new thing?) but because it's a useful solution. (CGI bins can be a pain for everyone, not just the server programmer)


What IS bothersome to me, is why people would choose "hot" over practical. why would consumers give anything that wasn't actually likely to improve their daily life a second thought? you're right, that there's "community support" but WHY? the same thing baffles me why there are so many bush supporters though it couldn't be simpler, he's bad at his job. start with 4 billion (or whatever) and end up in the negative billions. you can debate about the finer points of mismanaging a war, but that might require 4th grade level complexity. the budget thing is just clear cut, there is no subtltty to get. Likewise, a lot of computer tech is just blatantly useless or an impractical solution, to something that was hardly a problem. In many cases, like CSS, there was no problem, but a new wave of users (in about '99-'02), were impatient to make HTML more like print, rather than see they are very different animals.

It's great Google can use Ajax and the world map thing is a perfect example for them. But it's not one that applies to any of us. We don't have nearly that much info, or an audience as big who need to explore that much info. Even if we created an exact replica of the gooogle map, we just don't need to waste that much time creating millions of details, when maybe a thousand will ever be seen at most.


I am not arguing against knowing it though. remember image maps (before slices). that was cool, but now you rarely see em. browsers will still read em. you could surely run into a problem, where that'd be a good solution (needed it for a phrenology map a while ago). there are maybe 1 in 100 times, using meta tags for "push" animation has come up. hell, i bet there's a use for the <blink> tag (remember that?) things so rarely actually become obsolete.

i was just asking when could this possibly be useful? there aren't that many cases where you have a table of thousands of pieces of info, one would need scrolling precision to view, where a choice of buttons wouldn't be fine (though obviously a linear "forward", "back" buttons are just plain bad design). someone may really like info to slowly pan across the screen, rather than a "jump cut". but how is it worth the extra work to add that feature for this, if it means using the convoluted option instead of the easy one? ajax is hardly "neat" or "efficient". if it takes 5 times the work to add scrolling, it better be worth it.

if there's a practical reason to use it, i'm all for it. but if it's just "we climbed it because it was there", … just keep quiet.




Jason Van Anden wrote:

> Lewis - how so?
> (super weird gmail garbling of my last post -ack!)
> Jason
>
>
> On 2/6/06, Lewis LaCook <[email protected]> wrote:> well, once we
> start using a protocol more suited to network transmissions as>
> networks are NOW all of this will be moot–>>> lol>>>>>>>>>> Jason
> Van Anden <[email protected]> wrote:> Programmers tend to be
> skeptical of trendy new technologies,especially after> having invested
> so much time becoming expert in oneonly to be told it's> become
> obsolete. I suspect thatartist/programmers even more so, in that we>
> want to quickly create thethings we imagine, and the overhead of
> coding> often requires an bigdown payment.> I think this is the reason
> that Eric is emphasising the importance ofthis> particular technology
> (and also why some seem so hesitant).> There are many ways to do what
> AJAX does - and in that sense it isn'tnew.> Some of the reasons its so
> cool is:> 1.) its neat (clean, easy, elegant, efficient, etc…). It
> humanreadability> makes it a joy to code.> 2.) it has community
> support (unlike SOAP which I think did notcapture the> hearts of
> programmers because of its MS-centric syntax).Assuming> code/knowledge
> is being shared, this eliminates some of theoverhead> mentioned
> above.> 3.) it can drastically improve the user experience. At this
> point itworks on> most any browser so its easy to use and it allows
> for a moreefficient use of> bandwidth since it can significantly
> reduce thenumber of round trips and> amount of data being passed
> between theclient and server.> Fellow programmers, write this down,
> AJAX rocks, learn it an you willnot be> sorry.> More about it>
> here:http://www.adaptivepath.com/publications/essays/archives/000385.php> A very simple example of AJAX can be seen in my first foray into artwith a> political agenda called "Tax the Rich!" (link below). As faras I can tell> its the only "net art" piece of the bunch, but I'mafraid this is not a> compelling enough reason for people to view itover some of the sillier> entries.> http://tax.cf.huffingtonpost.com> Jason Van Anden>>> On 2/5/06, Pall Thayer>> wrote:> It's not necessarily about 'new' functionality per se. It's more>> about the user experience. It's about dynamic content in a seamless> and> invisible way. It's only what you need when you need it. When you> get a> table containing 500 elements, you don't need elements 200 to> 300 till you> scroll down. Of course, we could display the first 100> elements and then at> the bottom of the page is a 'next' link that> takes you to the next 100. But> let's say I'm on page 3 and I want to> go back and see item 78. The old way,> I go to the bottom of the page> and click on previous, and again, and then> locate 78. With AJAX, I> simply scroll back up (using two fingers on my> trackpad, which> incidentally isn't 'new' functionality either, just a> better, more> intuitive user experience. If you haven't tried it, it's> better than> it sounds). Try comparing google maps and mapquest and tell us> which> one "feels" better.>> Pall>> On 5.2.200!> 6, at 15:12, judson wrote:>> > true. but why is that particularly> important. either way, the> > client pushes a button and gets a result. if> that result is> > processed on the server or on their machine, there isn't> much> > difference to them. most users would never know, and certainly> >> none would ever care, if there's no benefit other than client side/> >> server side in and of itself.> >> > which is pretty much my point.> client-side technology is generally> > viewed as being more accessible, but> really it's mostly hype, and> > often no significant improvement or> simplification over server-side.> >> >> > On !
Feb 5, 2
006, at 12:36 PM, Pall> Thayer wrote:> >> >> No. Once the page is at the clients end,> PHP/Perl/whatever, isn't> >> doing anything.> >>> >> On 5.2.2006, at 11:36,> Plasma Studii wrote:> >>> >>> you can do the very same thing with PHP (or> Perl 10+ years ago).> >>> Ajax, Perl etc still read the whole page, but can> be told to load> >>> only part of it?> >>>> >>>>!> >>>> >>>> >>> Pall Thayer wrote:> >>>> >>>> I think you're m!> issing t> he point. It's not the ability to read or> >>>> write data to the server but> the ability to do so in a way that> >>>> doesn't require reloading the> entire page. Lets say person A in> >>>> Arkansas does something on the page> that rewrites the data in your> >>>> anything.txt file. Person B in Botswana> isn't going to see those> >>>> changes unless they reload the page. AJAX> lets you do the reloading> >>>> in the background. Probably the best use of> AJAX to this day, and> >>>> almost certainly a contributing factor to it's> renewed rise to> >>>> stardom (it's been around for a while) is Google maps.> It has> >>>> revolutionized the way maps are presented on the web. The> interface> >>>> is absolutely brilliant and a huge leap away from the old> method of> >>>> clicking on N, E, S or W to reload an image.> >>>>> >>>>> Palli> >>>>> >>>> On 5.2.2006, at 10:09, Plasma Studii wrote:> >>>>> >>>>>>> You will need to add the xmlrpc classes to your classpath, but> >>>>>> thats> trivial.> >>>>>>!> >>>>>> >>>>> hey eric,> >>>>>> >>>>> probably, i'm just not getting this,> but seems like the same> >>>>> result> >>>>> >>>>> would be SO much easier> with PHP? PHP is super clear, whereas> >>>>> Ajax> >>>>> >>>>> just isn't at> all. It's kinda the diff between intuitive and> >>>>> memorized. most folks> don't even notice how much they memorize(as> >>>>> opposed to understand),> but a lot seem like just arbitrary steps.> >>>>> sorta why reading/writing C> is actually FAR more intuitively> >>>>> comprehensible (though compilers are> usually convoluted) than> >>>>> anything in Flash.> >!
>>>>> >>
>>> the steps> to write to a file (any file on the web, not just> >>>>> XML) in> >>>>>> >>>>> PHP are clear. seems it would be a lot more "available to> >>>>>> artists"? is there some perk i'm missing here? Seems like> >>>>> bafflingly> convoluted MS design?> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write> >>>> to>> >>>>>!> if ( $FileOpen ) {> >>>>> fwrite( $FileOpen, "write whateve!> r you wa> nt, including HTML, XML> >>>>> or javascript code" );> >>>>> }> >>>>>> >>>>>> ?>> >>>>>> >>>>>> >>>>> that's ALL the code it takes!> >>>>>> >>>>> upload> it to a server running php (and about all of em do) this> >>>>> shows up on> the page (or it's included with osX, a download, etc).> >>>>> >>>>> the code> doesn't. if the page doesn't exist, it'll create it> >>>>> (though there's> also a file_exists() function you can use if you> >>>>> don't want that to> happen) the php could go absolutely> >>>>> anywhere on> >>>>> >>>>> your> HTML page. just name it x.php instead of x.html. it's> >>>>> designed with> the coder in mind, not the code (which is why i say> >>>>> an MS thing, they> seem to be incapable of thinking any way but> >>>>> from> >>>>> >>>>> their> own perspective)> >>>>>> >>>>>> >>>>> reminds me of depreciating the tag.> what possible> >>>>> improvement could you make by replacing it?! if it's> off by a> >>>>> pixel one in a thousand times, who cares?! (Web desig!> n just isn't> >>>>> print design and CSS and XHTML are just blatantly dumb> code> >>>>> design) the tag is well worth it just because it works so> clearly> >>>>> and without memorizing. Design utility extends to a lot more> than> >>>>> just Italian coffee makers and German cars. Code is another>> >>>>> appliance.> >>>>> +> >>>>> -> post: [email protected]> >>>>> ->> questions: [email protected]> >>>>> -> subscribe/unsubscribe:> http://rhizome.org/preferences/> >>>>> subscribe.rhiz> >>>>> -> give:> http://rhizome.org/support> >>>>> +> >>>>> Subscribers to Rhizome are> subject to!
the ter
ms set out in the> >>>>> Membership Agreement available> online at http://rhizome.org/info/> >>>>> 29.php> >>>>>> >>>>> >>>>> >>>>>> >>>> –> >>>> Pall Thayer> >>>> [email protected]> >>>>> http://www.this.is/pallit> >>>>> >>>>> >>>>> >>>>> >>> +> >>> -> post:> [email protected]> >>> -> questions: [email protected]> >>> ->> subscribe/unsubscribe: http://rhizome.org/preferences/> >>> subscribe.rhiz>> !> >>> -> give: http://rhizome.org/support> >>> +> >>> Subscriber!> s to Rhi> zome are subject to the terms set out in the> >>> Membership Agreement> available online at http://rhizome.org/info/> >>> 29.php> >>>> >>> >>> >>>> >> –> >> Pall Thayer> >> [email protected]> >>> http://www.this.is/pallit> >>> >>> >>> >>> >>> >>>>> –> Pall Thayer>> [email protected]> http://www.this.is/pallit>>>>> +> -> post:> [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe:> http://rhizome.org/preferences/subscribe.rhiz> -> give:> http://rhizome.org/support> +> Subscribers to Rhizome are subject to the> terms set out in the> Membership Agreement available online at> http://rhizome.org/info/29.php>>> –Jason Van Andenhttp://www.smileproject.com> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe:> http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>>>> ***************************************************************************>>> ||http://www.lewislacook.org||> sign up now! poetry, code, forums, blogs, newsfeeds…>>> ________________________________>> What are the most popular cars? Find out at Yahoo! Autos>>
>
> –Jason Van Andenhttp://www.smileproject.com

, MTAA

<this may be flame-ish>

+++

quoting plasma:
In many cases, like CSS, there was no problem, but a new wave of users
(in about '99-'02), were impatient to make HTML more like print,
rather than see they are very different animals.

+++

You don't see the utility of CSS? If you don't even understand the
benefit of CSS than this really is an impossible converstation to
have. CSS's value in a nutshell: separate the structure of the data
from it's presentation. In this way the data can be transformed in
it's presentation to handle different media: large screen, small
screen, print, screen reader etc.

Ajax is simply a technique. One that is being used to create user
interfaces that user's like better (when it is done well). Yes it's
'hot' right now, it has faddish glory. But it became popular because
developers understood that they could make platform-agonsitic web
applications that felt and acted like desktop applications to the end
user.

It's utility for artists is up to individual artists to decide. Some
examples of how i could have or will use it: If I had known about it
when making '1 year performance video,' it would have helped with
sending data to the server to increment viewer's time (it used a
hidden iframe to do it – a bad hack IMO). I'm also doing a piece that
requires voting. I send the vote to the server using XMLHttpRequest
then receive the current tally back to the browser and display it
without having to reload the entire page (like Digg).

On 2/6/06, Plasma Studii <[email protected]> wrote:
> ha ha. "to Ajax or not to Ajax" will probably be a moot point in a few years anyway. that's really not my question though. no, i don't mind obsoletism. though higher end tech, rarely becomes obsolete. C was around before most of us were born. Perl was probably around before the net. Java has existed since it was created. PHP is relatively new, but i do hope it survives (not because i can't learn a new thing?) but because it's a useful solution. (CGI bins can be a pain for everyone, not just the server programmer)
>
>
In many cases, like CSS, there was no problem, but a new wave of users
(in about '99-'02), were impatient to make HTML more like print,
rather than see they are very different animals.
>
> It's great Google can use Ajax and the world map thing is a perfect example for them. But it's not one that applies to any of us. We don't have nearly that much info, or an audience as big who need to explore that much info. Even if we created an exact replica of the gooogle map, we just don't need to waste that much time creating millions of details, when maybe a thousand will ever be seen at most.
>
>
> I am not arguing against knowing it though. remember image maps (before slices). that was cool, but now you rarely see em. browsers will still read em. you could surely run into a problem, where that'd be a good solution (needed it for a phrenology map a while ago). there are maybe 1 in 100 times, using meta tags for "push" animation has come up. hell, i bet there's a use for the <blink> tag (remember that?) things so rarely actually become obsolete.
>
> i was just asking when could this possibly be useful? there aren't that many cases where you have a table of thousands of pieces of info, one would need scrolling precision to view, where a choice of buttons wouldn't be fine (though obviously a linear "forward", "back" buttons are just plain bad design). someone may really like info to slowly pan across the screen, rather than a "jump cut". but how is it worth the extra work to add that feature for this, if it means using the convoluted option instead of the easy one? ajax is hardly "neat" or "efficient". if it takes 5 times the work to add scrolling, it better be worth it.
>
> if there's a practical reason to use it, i'm all for it. but if it's just "we climbed it because it was there", … just keep quiet.
>




<twhid>www.mteww.com</twhid>

, Jason Van Anden

Plasma Studii,
You bring up some really good points about past trends - I cancertainly understand feeling burned by over-hyped new tech. Beenthere, done that.
I have been programming (not html coding, but programming) sincearound 1979 - making my living with it since 1990. I am not sure Ineed to justify my free advice beyond that.
Jason Van Anden



On 2/6/06, Plasma Studii <[email protected]> wrote:> ha ha. "to Ajax or not to Ajax" will probably be a moot point in a few years anyway. that's really not my question though. no, i don't mind obsoletism. though higher end tech, rarely becomes obsolete. C was around before most of us were born. Perl was probably around before the net. Java has existed since it was created. PHP is relatively new, but i do hope it survives (not because i can't learn a new thing?) but because it's a useful solution. (CGI bins can be a pain for everyone, not just the server programmer)>>> What IS bothersome to me, is why people would choose "hot" over practical. why would consumers give anything that wasn't actually likely to improve their daily life a second thought? you're right, that there's "community support" but WHY? the same thing baffles me why there are so many bush supporters though it couldn't be simpler, he's bad at his job. start with 4 billion (or whatever) and end up in the negative billions. you can debate about the finer points of mismanaging a war, but that might require 4th grade level complexity. the budget thing is just clear cut, there is no subtltty to get. Likewise, a lot of computer tech is just blatantly useless or an impractical solution, to something that was hardly a problem. In many cases, like CSS, there was no problem, but a new wave of users (in about '99-'02), were impatient to make HTML more like print, rather than see they are very different animals.>> It's great Google can use Ajax and the world map thing is a perfect example for them. But it's not one that applies to any of us. We don't have nearly that much info, or an audience as big who need to explore that much info. Even if we created an exact replica of the gooogle map, we just don't need to waste that much time creating millions of details, when maybe a thousand will ever be seen at most.>>> I am not arguing against knowing it though. remember image maps (before slices). that was cool, but now you rarely see em. browsers will still read em. you could surely run into a problem, where that'd be a good solution (needed it for a phrenology map a while ago). there are maybe 1 in 100 times, using meta tags for "push" animation has come up. hell, i bet there's a use for the <blink> tag (remember that?) things so rarely actually become obsolete.>> i was just asking when could this possibly be useful? there aren't that many cases where you have a table of thousands of pieces of info, one would need scrolling precision to view, where a choice of buttons wouldn't be fine (though obviously a linear "forward", "back" buttons are just plain bad design). someone may really like info to slowly pan across the screen, rather than a "jump cut". but how is it worth the extra work to add that feature for this, if it means using the convoluted option instead of the easy one? ajax is hardly "neat" or "efficient". if it takes 5 times the work to add scrolling, it better be worth it.>> if there's a practical reason to use it, i'm all for it. but if it's just "we climbed it because it was there", … just keep quiet.>>>>> Jason Van Anden wrote:>> > Lewis - how so?> > (super weird gmail garbling of my last post -ack!)> > Jason> >> >> > On 2/6/06, Lewis LaCook <[email protected]> wrote:> well, once we> > start using a protocol more suited to network transmissions as>> > networks are NOW all of this will be moot–>>> lol>>>>>>>>>> Jason> > Van Anden <[email protected]> wrote:> Programmers tend to be> > skeptical of trendy new technologies,especially after> having invested> > so much time becoming expert in oneonly to be told it's> become> > obsolete. I suspect thatartist/programmers even more so, in that we>> > want to quickly create thethings we imagine, and the overhead of> > coding> often requires an bigdown payment.> I think this is the reason> > that Eric is emphasising the importance ofthis> particular technology> > (and also why some seem so hesitant).> There are many ways to do what> > AJAX does - and in that sense it isn'tnew.> Some of the reasons its so> > cool is:> 1.) its neat (clean, easy, elegant, efficient, etc…). It> > humanreadability> makes it a joy to code.> 2.) it has community> > support (unlike SOAP which I think did notcapture the> hearts of> > programmers because of its MS-centric syntax).Assuming> code/knowledge> > is being shared, this eliminates some of theoverhead> mentioned> > above.> 3.) it can drastically improve the user experience. At this> > point itworks on> most any browser so its easy to use and it allows> > for a moreefficient use of> bandwidth since it can significantly> > reduce thenumber of round trips and> amount of data being passed> > between theclient and server.> Fellow programmers, write this down,> > AJAX rocks, learn it an you willnot be> sorry.> More about it>> > here:http://www.adaptivepath.com/publications/essays/archives/000385.php> A very simple example of AJAX can be seen in my first foray into artwith a> political agenda called "Tax the Rich!" (link below). As faras I can tell> its the only "net art" piece of the bunch, but I'mafraid this is not a> compelling enough reason for people to view itover some of the sillier> entries.> http://tax.cf.huffingtonpost.com> Jason Van Anden>>> On 2/5/06, Pall Thayer>> wrote:> It's not necessarily about 'new' functionality per se. It's more>> about the user experience. It's about dynamic content in a seamless> and> invisible way. It's only what you need when you need it. When you> get a> table containing 500 elements, you don't need elements 200 to> 300 till you> scroll down. Of course, we could display the first 100> elements and then at> the bottom of the page is a 'next' link that> takes you to the next 100. But> let's say I'm on page 3 and I want to> go back and see item 78. The old w!> ay,> I go to the bottom of the page> and click on previous, and again, and then> locate 78. With AJAX, I> simply scroll back up (using two fingers on my> trackpad, which> incidentally isn't 'new' functionality either, just a> better, more> intuitive user experience. If you haven't tried it, it's> better than> it sounds). Try comparing google maps and mapquest and tell us> which> one "feels" better.>> Pall>> On 5.2.200!> 6, at 15:12, judson wrote:>> > true. but why is that particularly> important. either way, the> > client pushes a button and gets a result. if> that result is> > processed on the server or on their machine, there isn't> much> > difference to them. most users would never know, and certainly> >> none would ever care, if there's no benefit other than client side/> >> server side in and of itself.> >> > which is pretty much my point.> client-side technology is generally> > viewed as being more accessible, but> really it's mostly hype, and> > often no significant!> improvement or> simplification over server-side.> >> >> > On !> Feb 5, 2> 006, at 12:36 PM, Pall> Thayer wrote:> >> >> No. Once the page is at the clients end,> PHP/Perl/whatever, isn't> >> doing anything.> >>> >> On 5.2.2006, at 11:36,> Plasma Studii wrote:> >>> >>> you can do the very same thing with PHP (or> Perl 10+ years ago).> >>> Ajax, Perl etc still read the whole page, but can> be told to load> >>> only part of it?> >>>> >>>>!> >>>> >>>> >>> Pall Thayer wrote:> >>>> >>>> I think you're m!> issing t> he point. It's not the ability to read or> >>>> write data to the server but> the ability to do so in a way that> >>>> doesn't require reloading the> entire page. Lets say person A in> >>>> Arkansas does something on the page> that rewrites the data in your> >>>> anything.txt file. Person B in Botswana> isn't going to see those> >>>> changes unless they reload the page. AJAX> lets you do the reloading> >>>> in the background. Probably the best use of> AJAX to this day, and> >>>> almost certainly a contributing factor to it's> renewed rise to!> > >>>> stardom (it's been around for a while) is Google maps.> It has> >>>> revolutionized the way maps are presented on the web. The> interface> >>>> is absolutely brilliant and a huge leap away from the old> method of> >>>> clicking on N, E, S or W to reload an image.> >>>>> >>>>> Palli> >>>>> >>>> On 5.2.2006, at 10:09, Plasma Studii wrote:> >>>>> >>>>>>> You will need to add the xmlrpc classes to your classpath, but> >>>>>> thats> trivial.> >>>>>>!> >>>>>> >>>>> hey eric,> >>>>>> >>>>> probably, i'm just not getting this,> but seems like the same> >>>>> result> >>>>> >>>>> would be SO much easier> with PHP? PHP is super clear, whereas> >>>>> Ajax> >>>>> >>>>> just isn't at> all. It's kinda the diff between intuitive and> >>>>> memorized. most folks> don't even notice how much they memorize(as> >>>>> opposed to understand),> but a lot seem like just arbitrary steps.> >>>>> sorta why reading/writing C> is actually FAR more intuitively> >>>>> comprehensible (though compil!> ers are> usually convoluted) than> >>>>> anything in Flash.> >!> >>>>> >>> >>> the steps> to write to a file (any file on the web, not just> >>>>> XML) in> >>>>>> >>>>> PHP are clear. seems it would be a lot more "available to> >>>>>> artists"? is there some perk i'm missing here? Seems like> >>>>> bafflingly> convoluted MS design?> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> $FileOpen = fopen( "anything.txt", "w" ); // specify file to write> >>>> to>> >>>>>!> if ( $FileOpen ) {> >>>>> fwrite( $FileOpen, "write whateve!> r you wa> nt, including HTML, XML> >>>>> or javascript code" );> >>>>> }> >>>>>> >>>>>> ?>> >>>>>> >>>>>> >>>>> that's ALL the code it takes!> >>>>>> >>>>> upload> it to a server running php (and about all of em do) this> >>>>> shows up on> the page (or it's included with osX, a download, etc).> >>>>> >>>>> the code> doesn't. if the page doesn't exist, it'll create it> >>>>> (though there's> also a file_exists() function you can use if you> >>>>> don't want that to> happen) the php could go absolutely> >>>>> anywhere on> >>>>!> > >>>>> your> HTML page. just name it x.php instead of x.html. it's> >>>>> designed with> the coder in mind, not the code (which is why i say> >>>>> an MS thing, they> seem to be incapable of thinking any way but> >>>>> from> >>>>> >>>>> their> own perspective)> >>>>>> >>>>>> >>>>> reminds me of depreciating the tag.> what possible> >>>>> improvement could you make by replacing it?! if it's> off by a> >>>>> pixel one in a thousand times, who cares?! (Web desig!> n just isn't> >>>>> print design and CSS and XHTML are just blatantly dumb> code> >>>>> design) the tag is well worth it just because it works so> clearly> >>>>> and without memorizing. Design utility extends to a lot more> than> >>>>> just Italian coffee makers and German cars. Code is another>> >>>>> appliance.> >>>>> +> >>>>> -> post: [email protected]> >>>>> ->> questions: [email protected]> >>>>> -> subscribe/unsubscribe:> http://rhizome.org/preferences/> >>>>> subscribe.rhiz> >>>>> -> give:> http://rhizome.org/!> support> >>>>> +> >>>>> Subscribers to Rhizome are> subject to!> the ter> ms set out in the> >>>>> Membership Agreement available> online at http://rhizome.org/info/> >>>>> 29.php> >>>>>> >>>>> >>>>> >>>>>> >>>> –> >>>> Pall Thayer> >>>> [email protected]> >>>>> http://www.this.is/pallit> >>>>> >>>>> >>>>> >>>>> >>> +> >>> -> post:> [email protected]> >>> -> questions: [email protected]> >>> ->> subscribe/unsubscribe: http://rhizome.org/preferences/> >>> subscribe.rhiz>> !> >>> -> give: http://rhizome.org/support> >>> +> >>> Subscriber!> s to Rhi> zome are subject to the terms set out in the> >>> Membership Agreement> available online at http://rhizome.org/info/> >>> 29.php> >>>> >>> >>> >>>> >> –> >> Pall Thayer> >> [email protected]> >>> http://www.this.is/pallit> >>> >>> >>> >>> >>> >>>>> –> Pall Thayer>> [email protected]> http://www.this.is/pallit>>>>> +> -> post:> [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe:> http://rhizome.org/preferences/subscribe.rhiz> -> give:> http://rhizome.org/!> support> +> Subscribers to Rhizome are subject to the> terms set out in the> Membership Agreement available online at> http://rhizome.org/info/29.php>>> –Jason Van Andenhttp://www.smileproject.com> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe:> http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>>>> ***************************************************************************>>> ||http://www.lewislacook.org||> sign up now! poetry, code, forums, blogs, newsfeeds…>>> ________________________________>> What are the most popular cars? Find out at Yahoo! Autos>>> >> > –Jason Van Andenhttp://www.smileproject.com> +> -> post: [email protected]> -> questions: [email protected]> -> subscribe/unsubscribe: http://rhizome.org/preferences/subscribe.rhiz> -> give: http://rhizome.org/support> +> Subscribers to Rhizome are subject to the terms set out in the> Membership Agreement available online at http://rhizome.org/info/29.php>

–Jason Van Andenhttp://www.smileproject.comsheesh

, Plasma Studii

t.whid wrote:
> <this may be flame-ish>

no prob. from anyone else, i might be taken aback. but i've known you smell funny for a while, so i don't take it personally!

>
> +++
>
> quoting plasma:
> In many cases, like CSS, there was no problem, but a new wave of users
> (in about '99-'02), were impatient to make HTML more like print,
> rather than see they are very different animals.
>
> +++
>
> You don't see the utility of CSS?

nope. just the opposite. think it does more harm than good. because it forces people to think of "web pages" as pages, not simply collections of data (in some order, but not a layout)

> CSS's value in a nutshell: separate the structure of the data
> from it's presentation.

that's a great goal, but not what styles ultimately do. they neither simplify the design process (a supposed benefit of separating it from the HTML (which was designed so anyone could easily learn it)), nor speed up the processing.

Apples data fork is genius. does both. also seperates text for multiple languages. obvioously not all designers will read C, so they can use res-edit. the reason macs were so much faster at graphics and audio for so many years, is different parts of the computer handle different tasks, with different efficiency. (though nowadays the over-all parts have all gotten so much better, a little inefficiency hardly shows.) that' could be another reason to split them up.

div tags alone would be great. but styles make for "spaghetti code" and put far too much emphasis on print-like rigid layout. that much layout control isn't neccessary, it's a chosen addition. serves no actual purpose, just an inability to see things without it.

> If I had known about it
> when making '1 year performance video,' it would have helped with
> sending data to the server to increment viewer's time (it used a
> hidden iframe to do it – a bad hack IMO).

trivia: actually, the whole thing could have easily been done with a couple lines of code. assumed that's the way you used. But whatever works.

, ryan griffis

>>
>> You don't see the utility of CSS?
>
> nope. just the opposite. think it does more harm than good. because
> it forces people to think of "web pages" as pages, not simply
> collections of data (in some order, but not a layout)

just a simple (i think) point here. CSS doesn't "force" anyone to think
of web documents is any way. You don't have to use CSS to create
layouts, you can still use the simple xml/xhtml/html (whatever you
think you're typing anymore) and just let the pieces fall in their
default L-R/vertical order.
but the arg that twid's making is important - with css (or some
parallel system if there's a better one) the data can be created in one
document and formated by various devices (or if you're a populist, by
the user/reader/audience). i don't know about you, but i don't know of
any print publication technologies that do that on demand. this is
great for ideas like accessibility, preservation, transference and
flexibility. i don't get how any of this makes web docs any more of a
page than tablular layouts did.

, MTAA

On 2/6/06, Plasma Studii <[email protected]> wrote:
> t.whid wrote:
> > <this may be flame-ish>
>
> no prob. from anyone else, i might be taken aback. but i've known you smell funny for a while, so i don't take it personally!
>
> >

I'm glad you don't take it personally. And you're right, just ask my
friends and co-workers, I smell funny.

> > +++
> >
> > quoting plasma:
> > In many cases, like CSS, there was no problem, but a new wave of users
> > (in about '99-'02), were impatient to make HTML more like print,
> > rather than see they are very different animals.
> >
> > +++
> >
> > You don't see the utility of CSS?
>
> nope. just the opposite. think it does more harm than good. because it forces people to think of "web pages" as pages, not simply collections of data (in some order, but not a layout)
>

argh! That's what CSS does! There is no layout in XHTML except the
default styles that the browser gives it. There is an order
<head><body><h1>, but no layout – CSS provides the layout and you can
make styles for all different ways to display it.

> > CSS's value in a nutshell: separate the structure of the data
> > from it's presentation.
>
> that's a great goal, but not what styles ultimately do. they neither simplify the design process (a supposed benefit of separating it from the HTML (which was designed so anyone could easily learn it)), nor speed up the processing.
>

You make this statement 'not what styles ultimately do' but you don't
back it up with any examples or any reasoning whatsoever. See
http://www.csszengarden.com/ for an example of how different styles
can completely change the way an XHTML file, using the same exact
mark-up, can be presented.

>
> div tags alone would be great. but styles make for "spaghetti code" and put far too much emphasis on print-like rigid layout. that much layout control isn't neccessary, it's a chosen addition. serves no actual purpose, just an inability to see things without it.

How do styles make 'spaghetti code?' A well marked-up XHTML file
combined with a well-structured stylesheet is very simple to read. No
ziti, no spaghetti, not even a caeser salad to start.

>
> > If I had known about it
> > when making '1 year performance video,' it would have helped with
> > sending data to the server to increment viewer's time (it used a
> > hidden iframe to do it – a bad hack IMO).
>
> trivia: actually, the whole thing could have easily been done with a couple lines of code. assumed that's the way you used. But whatever works.

Please elaborate – I had to talk to the DB on the server, it wasn't
much data to send, but I couldn't reload the page everytime, it would
have completely destroyed the viewer experience (I probably could have
and should have done it in the flash movie, but I didn't). So I ended
up sending it thru a hidden frame. XMLHTTPRequest would have worked
better but the techniques hadn't been developed fully at the time.


<twhid>www.mteww.com</twhid>

, Plasma Studii

>>> You don't see the utility of CSS?

>> nope. just the opposite. think it does more harm than good. because it forces people to think of "web pages" as pages, not simply collections of data (in some order, but not a layout)

> argh! That's what CSS does!

??? (maybe you thought we were referring to XML here?)


>>> CSS's value in a nutshell: separate the structure of the data
from it's presentation.

>> that's a great goal, but not what styles ultimately do. they neither simplify the design process (a supposed benefit of separating it from the HTML (which was designed so anyone could easily learn it)), nor speed up the processing.

> You make this statement 'not what styles ultimately do' but you don't
back it up with any examples or any reasoning whatsoever. See
http://www.csszengarden.com/ for an example of how different styles
can completely change the way an XHTML file, using the same exact
mark-up, can be presented.

use a browser for the blind. content is not just design. and design isn't the only vehicle for content.



>> div tags alone would be great. but styles make for "spaghetti code" and put far too much emphasis on print-like rigid layout. that much layout control isn't neccessary, it's a chosen addition. serves no actual purpose, just an inability to see things without it.

> How do styles make 'spaghetti code?' A well marked-up XHTML file
combined with a well-structured stylesheet is very simple to read. No
ziti, no spaghetti, not even a caeser salad to start.

the style declarations are in the header or sometimes in a separate file. then often referred to in the javascript. then again in the body. then there's #def section that is often after the script. why remember?

Flash is far worse in this respect, but i like to know where all the code is in one consistent spot without hunting around. the BASIC command GOTO usually instigates complaints about encouraging "speghetti code". you have to follow it as it jumps from section to section.

makes debugging more clear when you don't have to guess where some code would be. i'm sure CSS can be done neatly, but usually isn't. but that's hardly the worst problem. the worst is the conceptuaol page layout vs. screenful of info thing.


>>> If I had known about it
when making '1 year performance video,' it would have helped with
sending data to the server to increment viewer's time (it used a
hidden iframe to do it – a bad hack IMO).

>> trivia: actually, the whole thing could have easily been done with a couple lines of code. assumed that's the way you used. But whatever works.

> Please elaborate – I had to talk to the DB on the server, it wasn't
much data to send, but I couldn't reload the page everytime, it would
have completely destroyed the viewer experience (I probably could have
and should have done it in the flash movie, but I didn't). So I ended
up sending it thru a hidden frame. XMLHTTPRequest would have worked
better but the techniques hadn't been developed fully at the time.

the wonderful thing about PHP is it is so readable. The actual mechanics of this aren't crucial to get the idea…



<html> <! <- you don't really need this or it's end tag, but this illustraters the idea>
<body>

check out the artists now!<p>

<?

$Now = date("h"); // or whatever letter for hour in military is, but you get a number 0-23
$RandomNo = rand(1,9); // for fun
print ("<embed src=clips/$RandomNo/clip$Now.mov width$0 height0><p>");

?>

</body>
</html>


generally, on the web, a db doesn't contain media, so much as refers to where it's stored, and some searchable tag-like text. you can often skip em, by just using variables when you specify the path. why i was saying databases really only start to become handy, when you have a humongous amount of data and organization becomes more important (as in google maps or a big inventory).

, MTAA

(why, oh why do i get into these ridiculous args online… one day
i'll learn…)


On 2/6/06, Plasma Studii <[email protected]> wrote:
> >>> You don't see the utility of CSS?
>
> >> nope. just the opposite. think it does more harm than good. because it forces people to think of "web pages" as pages, not simply collections of data (in some order, but not a layout)
>
> > argh! That's what CSS does!
>
> ??? (maybe you thought we were referring to XML here?)
>

do you just want to be difficult? This is totally ridiculous!

ah no, xml in the form of XHTML is the strucure, what allows this
structure to be presented? Currently on the web it's done with CSS.

>
> >>> CSS's value in a nutshell: separate the structure of the data
> from it's presentation.
>
> >> that's a great goal, but not what styles ultimately do. they neither simplify the design process (a supposed benefit of separating it from the HTML (which was designed so anyone could easily learn it)), nor speed up the processing.
>
> > You make this statement 'not what styles ultimately do' but you don't
> back it up with any examples or any reasoning whatsoever. See
> http://www.csszengarden.com/ for an example of how different styles
> can completely change the way an XHTML file, using the same exact
> mark-up, can be presented.
>
> use a browser for the blind. content is not just design. and design isn't the only vehicle for content.
>

ARGH! THAT'S MY POINT! The CONTENT, ie, MARKED-UP DATA is separate
from the presentation. So a blind person can use a screen reader
without a bunch of tabular hacky cruft and someone with a nice big
monitor can see a beautiful layout. This is precisely what CSS media
types are for (http://www.w3schools.com/css/css_mediatypes.asp)!

Why you continue not to access this simple idea is beyond me.

>
>
> >> div tags alone would be great. but styles make for "spaghetti code" and put far too much emphasis on print-like rigid layout. that much layout control isn't neccessary, it's a chosen addition. serves no actual purpose, just an inability to see things without it.
>
> > How do styles make 'spaghetti code?' A well marked-up XHTML file
> combined with a well-structured stylesheet is very simple to read. No
> ziti, no spaghetti, not even a caeser salad to start.
>
> the style declarations are in the header or sometimes in a separate file. then often referred to in the javascript. then again in the body. then there's #def section that is often after the script. why remember?
>

to each his own i suppose, i guess it's a subjective thing. it seems
you're talking more about all the diff web tech than CSS in
particular.

> Flash is far worse in this respect, but i like to know where all the code is in one consistent spot without hunting around. the BASIC command GOTO usually instigates complaints about encouraging "speghetti code". you have to follow it as it jumps from section to section.
>
> makes debugging more clear when you don't have to guess where some code would be. i'm sure CSS can be done neatly, but usually isn't. but that's hardly the worst problem. the worst is the conceptuaol page layout vs. screenful of info thing.
>
>
> >>> If I had known about it
> when making '1 year performance video,' it would have helped with
> sending data to the server to increment viewer's time (it used a
> hidden iframe to do it – a bad hack IMO).
>
> >> trivia: actually, the whole thing could have easily been done with a couple lines of code. assumed that's the way you used. But whatever works.
>
> > Please elaborate – I had to talk to the DB on the server, it wasn't
> much data to send, but I couldn't reload the page everytime, it would
> have completely destroyed the viewer experience (I probably could have
> and should have done it in the flash movie, but I didn't). So I ended
> up sending it thru a hidden frame. XMLHTTPRequest would have worked
> better but the techniques hadn't been developed fully at the time.
>

I have no idea what you were tryiing to communicate with that little
PHP script below..

> the wonderful thing about PHP is it is so readable. The actual mechanics of this aren't crucial to get the idea…
>
> —
>
> <html> <! <- you don't really need this or it's end tag, but this illustraters the idea>
> <body>
>
> check out the artists now!<p>
>
> <?
>
> $Now = date("h"); // or whatever letter for hour in military is, but you get a number 0-23
> $RandomNo = rand(1,9); // for fun
> print ("<embed src=clips/$RandomNo/clip$Now.mov width$0 height0><p>");
>
> ?>
>
> </body>
> </html>
>

Perhaps you've never seen the piece? That's fair. It has two videos
playing in flash embedded in an XHTML page. These videos are loaded
dynamically by talking to a php script on the server. Part of the
piece is that a user is supposed to watch it for a year. The site
keeps track of how long they've watched it. How does it keep track?
Every minute the client needs to tell the server that the page is
still open and being viewed. If the page refreshes, that could do it,
but that would ruin the streaming video effect. So i use hidden frame
to load a php script that increments the veiwer's time in the db. My
point was simply that it would have been better to do it with
XMLHTTPRequest instead of the hidden frame for reasons i don't feel
like going into.


<twhid>www.mteww.com</twhid>

, Plasma Studii

well you sound bored with it and i definitely am, so i'll just say this and i'm taking off.


my responce is same as my initial responce, to what end benefit? Folks seem to be talking from the perspective that a web page is and can only be code + design. that's the common view now and has been for a few years. Totally agree it's the status quo, but am saying there's also a different way to look at it, more common in the 90's. HTML can be about delivery not packaging.

"web design" exists now anyway, obviously. but design, although popular, does not need to be a crucial part of the concept, just as leashes are not an essential feature in dogs. HTML gives a rough idea of the order of media placement and download scheduling, but the resulting look has been confused with imperfect layout of graphics. in that way, the difference in the amount of control available with CSS, as opposed to HTML is an artifact of a print perspective, not a file delivery perspective. and from either perspective, CSS certainly doesn't simplify the task of writing it nor helps significantly in downloading it. it's a lousy solution, even if there were a real problem.


you may see a benefit, i don't. ok fine. both the art world and web world somehow attract a lot of folks who appreciate what looks to me just like hype. it may be something real but no one can both see it and articulate it to someone who can't.


whid wrote:

> (why, oh why do i get into these ridiculous args online… one day
> i'll learn…)
>
>
> On 2/6/06, Plasma Studii <[email protected]> wrote:
> > >>> You don't see the utility of CSS?
> >
> > >> nope. just the opposite. think it does more harm than good.
> because it forces people to think of "web pages" as pages, not simply
> collections of data (in some order, but not a layout)
> >
> > > argh! That's what CSS does!
> >
> > ??? (maybe you thought we were referring to XML here?)
> >
>
> do you just want to be difficult? This is totally ridiculous!
>
> ah no, xml in the form of XHTML is the strucure, what allows this
> structure to be presented? Currently on the web it's done with CSS.
>
> >
> > >>> CSS's value in a nutshell: separate the structure of the data
> > from it's presentation.
> >
> > >> that's a great goal, but not what styles ultimately do. they
> neither simplify the design process (a supposed benefit of separating
> it from the HTML (which was designed so anyone could easily learn
> it)), nor speed up the processing.
> >
> > > You make this statement 'not what styles ultimately do' but you
> don't
> > back it up with any examples or any reasoning whatsoever. See
> > http://www.csszengarden.com/ for an example of how different styles
> > can completely change the way an XHTML file, using the same exact
> > mark-up, can be presented.
> >
> > use a browser for the blind. content is not just design. and
> design isn't the only vehicle for content.
> >
>
> ARGH! THAT'S MY POINT! The CONTENT, ie, MARKED-UP DATA is separate
> from the presentation. So a blind person can use a screen reader
> without a bunch of tabular hacky cruft and someone with a nice big
> monitor can see a beautiful layout. This is precisely what CSS media
> types are for (http://www.w3schools.com/css/css_mediatypes.asp)!
>
> Why you continue not to access this simple idea is beyond me.
>
> >
> >
> > >> div tags alone would be great. but styles make for "spaghetti
> code" and put far too much emphasis on print-like rigid layout. that
> much layout control isn't neccessary, it's a chosen addition. serves
> no actual purpose, just an inability to see things without it.
> >
> > > How do styles make 'spaghetti code?' A well marked-up XHTML file
> > combined with a well-structured stylesheet is very simple to read.
> No
> > ziti, no spaghetti, not even a caeser salad to start.
> >
> > the style declarations are in the header or sometimes in a separate
> file. then often referred to in the javascript. then again in the
> body. then there's #def section that is often after the script. why
> remember?
> >
>
> to each his own i suppose, i guess it's a subjective thing. it seems
> you're talking more about all the diff web tech than CSS in
> particular.
>
> > Flash is far worse in this respect, but i like to know where all the
> code is in one consistent spot without hunting around. the BASIC
> command GOTO usually instigates complaints about encouraging
> "speghetti code". you have to follow it as it jumps from section to
> section.
> >
> > makes debugging more clear when you don't have to guess where some
> code would be. i'm sure CSS can be done neatly, but usually isn't.
> but that's hardly the worst problem. the worst is the conceptuaol
> page layout vs. screenful of info thing.
> >
> >
> > >>> If I had known about it
> > when making '1 year performance video,' it would have helped with
> > sending data to the server to increment viewer's time (it used a
> > hidden iframe to do it – a bad hack IMO).
> >
> > >> trivia: actually, the whole thing could have easily been done
> with a couple lines of code. assumed that's the way you used. But
> whatever works.
> >
> > > Please elaborate – I had to talk to the DB on the server, it
> wasn't
> > much data to send, but I couldn't reload the page everytime, it
> would
> > have completely destroyed the viewer experience (I probably could
> have
> > and should have done it in the flash movie, but I didn't). So I
> ended
> > up sending it thru a hidden frame. XMLHTTPRequest would have worked
> > better but the techniques hadn't been developed fully at the time.
> >
>
> I have no idea what you were tryiing to communicate with that little
> PHP script below..
>
> > the wonderful thing about PHP is it is so readable. The actual
> mechanics of this aren't crucial to get the idea…
> >
> > —
> >
> > <html> <! <- you don't really need this or it's end tag, but this
> illustraters the idea>
> > <body>
> >
> > check out the artists now!<p>
> >
> > <?
> >
> > $Now = date("h"); // or whatever letter for hour in military is, but
> you get a number 0-23
> > $RandomNo = rand(1,9); // for fun
> > print ("<embed src=clips/$RandomNo/clip$Now.mov width$0
> height0><p>");
> >
> > ?>
> >
> > </body>
> > </html>
> >
>
> Perhaps you've never seen the piece? That's fair. It has two videos
> playing in flash embedded in an XHTML page. These videos are loaded
> dynamically by talking to a php script on the server. Part of the
> piece is that a user is supposed to watch it for a year. The site
> keeps track of how long they've watched it. How does it keep track?
> Every minute the client needs to tell the server that the page is
> still open and being viewed. If the page refreshes, that could do it,
> but that would ruin the streaming video effect. So i use hidden frame
> to load a php script that increments the veiwer's time in the db. My
> point was simply that it would have been better to do it with
> XMLHTTPRequest instead of the hidden frame for reasons i don't feel
> like going into.
>
> –
> <twhid>www.mteww.com</twhid>
>

, Rob Myers

Quoting "T.Whid" <[email protected]>:

>> $Now = date("h"); // or whatever letter for hour in military is, but
>> you get a number 0-23
>> $RandomNo = rand(1,9); // for fun
>> print ("<embed src=clips/$RandomNo/clip$Now.mov width$0 height0><p>");
>>
>> ?>
>>
>> </body>
>> </html>
>>
>
> Perhaps you've never seen the piece?

Never mind having seen the piece, this snippet is exactly the kind of
confusion
of presentation and content that XML + CSS is designed to avoid. Page
scripting
languages like PHP are notorious for encouraging people to tightly bind logic
and presentation. Sure you can use them to generate XML, but then
you're better
off using a CMS for any non-trivial examples.

XML = data.
CSS = presentation.
PHP = a method of generating either on the server.
AJAX = a way of updating either on the client without refreshing the page.

AJAX is hype, but the underlying techniques may be useful to artists.

- Rob.

, Eric Dymond

The main problem you haven't addressed, is that PHP is not stateful the way the java server program I posted last week IS.
It will run in the background and send xmlrpc messages in a stateful way. This will allow for interactive, real time, messaging, forwarding, and anything else you can imagine (querying user hits, accessing listerv announcements).
You could easily set up a messaging service with the code I posted earlier that allowed a web page to post new notification in a div, span or any named element without reloading.
Real time can be set with a setInterval callback.
There is a HUGE difference between PHP (not stateful) and a java program running off a selected port (say 8245 or anything between 1561 and 64,xxx ).
The server can easily run in the background while the web page with the xmlhttp object makes times calls to the IN STATE server.
Now does that help?
Please, try the code before you react or make any more comments.
Eric