ARTBASE (1)
BIO
born in 1962 in Lier, Belgium.
studied filology at Louvain, Belgium.
worked a lot in bars and restaurants before i became obsessivly addicted to producing stuff on computers.
i once won a design contest of cgi-magazine and they let me go to New York for four days, that was nice.
i think in terms of writing mostly (or programming, but those are very similar processes for me)
painting is a very different process and i'm very bad at it but i do it anyway because i like the differences it produces and i like the freshness of amateurism, i guess.
what i produce new media-wise is also very much influenced by my daily practice of webdesign and programming with its concerns of usability and the pragmatic approach it implies.
studied filology at Louvain, Belgium.
worked a lot in bars and restaurants before i became obsessivly addicted to producing stuff on computers.
i once won a design contest of cgi-magazine and they let me go to New York for four days, that was nice.
i think in terms of writing mostly (or programming, but those are very similar processes for me)
painting is a very different process and i'm very bad at it but i do it anyway because i like the differences it produces and i like the freshness of amateurism, i guess.
what i produce new media-wise is also very much influenced by my daily practice of webdesign and programming with its concerns of usability and the pragmatic approach it implies.
Re: Re: Re: AJAX for artists
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
dv@vilt.net
http://www.vilt.net
http://www.viltdigitalvision.com
> -----Oorspronkelijk bericht-----
> Van: owner-list@rhizome.org [mailto:owner-list@rhizome.org]
> Namens Eric Dymond
> Verzonden: zondag 5 februari 2006 6:07
> Aan: list@rhizome.org
> 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: list@rhizome.org
> -> questions: info@rhizome.org
> -> 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
>
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
dv@vilt.net
http://www.vilt.net
http://www.viltdigitalvision.com
> -----Oorspronkelijk bericht-----
> Van: owner-list@rhizome.org [mailto:owner-list@rhizome.org]
> Namens Eric Dymond
> Verzonden: zondag 5 februari 2006 6:07
> Aan: list@rhizome.org
> 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: list@rhizome.org
> -> questions: info@rhizome.org
> -> 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
>
Re: nznl.com digest, Jan 26, 2006 - Feb 01, 2006
always love it, but the seepage javascript thing is just plain brilliant.
bravo.
dv
_____
Van: owner-list@rhizome.org [mailto:owner-list@rhizome.org] Namens Geert
Dekkers
Verzonden: woensdag 1 februari 2006 23:03
Aan: Rhizome
CC: webartery; WRYTING-L : Writing and Theory across Disciplines;
NetBehaviour for networked distributed creativity; nettime-nl@nettime.org;
nettime-ann@nettime.org
Onderwerp: RHIZOME_RAW: nznl.com digest, Jan 26, 2006 - Feb 01, 2006
listnznl.com digest
Jan 26, 2006 - Feb 01, 2006
Posts 1340 - 1346
http://nznl.com
1340. Jan 26, 2006
STUDY, 2010, STUDY
web page
http://nznl.com/geert/pop.php?dag 060126
1341. Jan 27, 2006
BODIES, 2010, BODIES
photoshop/fireworks file
http://nznl.com/geert/pop.php?dag 060127
1342. Jan 28, 2006
PLAN FOR AN IMAGE OF THE NZNL.COM EXHIBITION HALL WATER SUPPLY IN
JAVASCRIPT, 2010, STUDY FOR A SOFTWARE DESIGN
converted keynote file
http://nznl.com/geert/pop.php?dag 060128
1343. Jan 29, 2006
STUDY FOR A JAVASCRIPT FAUCET, 2010, PLAN FOR A JAVASCRIPT WATER SYSTEM,
DETAIL
web page
http://nznl.com/geert/pop.php?dag 060129
1344. Jan 30, 2006
WATER CLOSET, 2010, WATER CLOSET
photoshop/fireworks file
http://nznl.com/geert/pop.php?dag 060130
1345. Jan 31, 2006
SEEPAGE, 2010, SEEPAGE
photoshop/fireworks file
http://nznl.com/geert/pop.php?dag 060131
1346. Feb 01, 2006
JAVASCRIPT SEEPAGE, 2010, JAVASCRIPT SEEPAGE
web page
http://nznl.com/geert/pop.php?dag 060201
Geert Dekkers
http://nznl.com
bravo.
dv
_____
Van: owner-list@rhizome.org [mailto:owner-list@rhizome.org] Namens Geert
Dekkers
Verzonden: woensdag 1 februari 2006 23:03
Aan: Rhizome
CC: webartery; WRYTING-L : Writing and Theory across Disciplines;
NetBehaviour for networked distributed creativity; nettime-nl@nettime.org;
nettime-ann@nettime.org
Onderwerp: RHIZOME_RAW: nznl.com digest, Jan 26, 2006 - Feb 01, 2006
listnznl.com digest
Jan 26, 2006 - Feb 01, 2006
Posts 1340 - 1346
http://nznl.com
1340. Jan 26, 2006
STUDY, 2010, STUDY
web page
http://nznl.com/geert/pop.php?dag 060126
1341. Jan 27, 2006
BODIES, 2010, BODIES
photoshop/fireworks file
http://nznl.com/geert/pop.php?dag 060127
1342. Jan 28, 2006
PLAN FOR AN IMAGE OF THE NZNL.COM EXHIBITION HALL WATER SUPPLY IN
JAVASCRIPT, 2010, STUDY FOR A SOFTWARE DESIGN
converted keynote file
http://nznl.com/geert/pop.php?dag 060128
1343. Jan 29, 2006
STUDY FOR A JAVASCRIPT FAUCET, 2010, PLAN FOR A JAVASCRIPT WATER SYSTEM,
DETAIL
web page
http://nznl.com/geert/pop.php?dag 060129
1344. Jan 30, 2006
WATER CLOSET, 2010, WATER CLOSET
photoshop/fireworks file
http://nznl.com/geert/pop.php?dag 060130
1345. Jan 31, 2006
SEEPAGE, 2010, SEEPAGE
photoshop/fireworks file
http://nznl.com/geert/pop.php?dag 060131
1346. Feb 01, 2006
JAVASCRIPT SEEPAGE, 2010, JAVASCRIPT SEEPAGE
web page
http://nznl.com/geert/pop.php?dag 060201
Geert Dekkers
http://nznl.com
scary monsters
Some Frames (Are Always On)
(...a scroll 4 our son who's having trouble sleeping alone at night
lately...)
http://www.vilt.net/nkdee/frames.jsp
greetings,
dv @ Neue Kathedrale des erotischen Elends
http://www.vilt.net/nkdee
(...a scroll 4 our son who's having trouble sleeping alone at night
lately...)
http://www.vilt.net/nkdee/frames.jsp
greetings,
dv @ Neue Kathedrale des erotischen Elends
http://www.vilt.net/nkdee
Re: US Plans to 'Fight the Net' Revealed
A second consequence of this new state of war is that international
relations and domestic politics become increasingly similar and
intermingled. In the context of this cross between military and police
activity aimed at security there is ever less difference between inside and
outside the nation-state: low-intensity warfare meets high-intensity police
actions, The "enemy", which has traditionally been conceived outside, and
the "dangerous classes," which have traditionally been inside, are thus
increasingly indistinguishable from one another and serve together as the
object of the war effort."
Hardt, Michael & Negri, Antonio in "Multitude: war and democracy in the Age
of Empire", p.14 (http://en.wikipedia.org/wiki/Toni_Negri)
However, inside the Cathedral, allegedly located at 50
relations and domestic politics become increasingly similar and
intermingled. In the context of this cross between military and police
activity aimed at security there is ever less difference between inside and
outside the nation-state: low-intensity warfare meets high-intensity police
actions, The "enemy", which has traditionally been conceived outside, and
the "dangerous classes," which have traditionally been inside, are thus
increasingly indistinguishable from one another and serve together as the
object of the war effort."
Hardt, Michael & Negri, Antonio in "Multitude: war and democracy in the Age
of Empire", p.14 (http://en.wikipedia.org/wiki/Toni_Negri)
However, inside the Cathedral, allegedly located at 50
not exactly George W. Bush beaten to lifeless pulp by swarm of angry kindergarten children
rather
g*d on a Kabakovian approach to real time
(dv, flash 8 - interactive multi-dimensional video , 1725kb)
<http://www.vilt.net/nkdee/kabakov.jsp>
http://www.vilt.net/nkdee/kabakov.jsp
greetings,
dv @ Neue Kathedrale des erotischen Elends
http://www.vilt.net/nkdee
g*d on a Kabakovian approach to real time
(dv, flash 8 - interactive multi-dimensional video , 1725kb)
<http://www.vilt.net/nkdee/kabakov.jsp>
http://www.vilt.net/nkdee/kabakov.jsp
greetings,
dv @ Neue Kathedrale des erotischen Elends
http://www.vilt.net/nkdee