AltME groups: search

Maybe Jaime or Ladislav can tell us whether we can build a Pastry 
like network upon Beer.

I guess one problem with a multicast tree is that if you're disseminating 
your RSS feed this way, you may not know how many subscribers there 
are.

No. We need to get out of the browser. A place like that should have 
a REBOL client! :-)

http://pages.google.comgoogle just launched a new beta... They are 
gooing and going faster faster...

got a pc and want to run OSX on it ? try this then :   http://maxxuss.konglish.org/

Hope they can deliver on this: "Vista will include a built-in speech 
recognition engine, and new and improved speech synthesis. Assuming 
it works as well as it should, you'll be able to dictate emails or 
give voice commands for web navigations without buying additional 
speech recognition software."

Only have to buy a new PC to accomodate the hardware requirements 
of vista.

Internet Explorer 7 under Windows Vista runs in a special super-low 
user access mode that gives the browser very little access to the 
underlying OS, and ActiveX security has been tightened up significantly 
as well, with most ActiveX controls off by default and set to opt-in 
rather than opt-out. Hopefully other browsers will follow suit and 
operate in this least-privileged mode, too.
 - Like IE is a model of good security practices!?

Well lets see. according to yahoo, Microsoft has revenues of $41 
billion, a 31% profit margin, total cash of $34 billion, a $15 billion 
operating cash flow, and a market cap of $277.66 Billion.

Thats BILLION as in $1000 million.

But hey, what do they know?

but wait! I just forgot terry comes from a parallel universe. it 
makes sense that windows does not suck there.

i'm not the one that can write the roadmap, so i can only tell you 
what i am told. i was told "soon" (in the sense of a few days)

I will be going by Redwood Valley on Saturday and give Carl a "reboot" 
:)

:-)) but please, only a software reboot, not hard-reboot, right? 
:-)

Have a nice visit Alan ;-)

http://www.engadget.com/2006/03/01/not-content-as-a-mere-sideline-mascot-tux-now-runs-linux/

Cute...

Here's a good read.. 

The future of HTML, Part 1: WHATWG
http://www-128.ibm.com/developerworks/library/x-futhtml1/

In my universe, back in the early 80s, I went with windows, simply 
becuase I couldn't afford a mac. Best computing decision i ever made. 
 Wish I bought stock.

Terry, I think computing is mature enough to have machines for different 
purposes, games machines, media machines and work machines. Most 
households I know have a least two on that list so far and are heading 
for the 3rd. Currently the pendulum is swinging away from "one machine 
to rule them all".

thankfully we are in a time of plenty in our neck of the woods at 
the moment.

I've been telling people foy years to get a machine for work and 
a machine to trash for games etc.

Because if they call me (as they often do) and say "I've broken my 
only computer by downloading a game and now I can't get it to work 
and I've got to do something important" they get zero sympathy and 
I'm pretty dis-inclined to lend a hand in fixing their crisis.

Of course, those of us with only one computer must equip ourselves 
with a little common sense to avoid pain. Funny when I watch my friend 
end up trashing all of his machines because he is not similarly equipped.

I'm guilty. But I think below a certain threshold, people tend to 
spend all their available money on the one computer, in order to 
make it as good as possible. That's my reasoning from years ago. 
These days, I feel quite different. I don't feel like playing games 
much anymore and I'm pretty careful installing new software.

  MySQL 5.0 Adds Features for Enterprise Developers and DBAs
by Ken 
  North

Baseball legend Satchel Paige is famous for having said 

Don't look back, something might be gaining on you." Companies selling 
a commercial SQL database management system (DBMS) know its MySQL 
that's gaining on them. With an already large installed base, MySQL 
is set to attract new users because of the feature set of version 
5.0. It includes capabilities for which developers have often turned 
to commercial SQL products.


The purposes for which we use personal, mobile, workgroup, departmental, 
enterprise and web databases are diverse. Application requirements 
are a primary determinant of the capacity and features we need from 
an SQL DBMS. For example, a high-volume transaction processing web 
site places greater demands on a database than a contact list manager 
for laptops and small business servers.


A Web Techniques magazine article, "Web Databases: Fun with Guests 
or Risky Business?" discussed features that characterize an industrial-grade 
SQL DBMS. It explained SQL security and mission-critical databases, 
defined as


    "A database is mission critical if its lack of data integrity has 
    serious consequences, such as causing the loss of customers or even 
    lives."


Maintaining data integrity is implicit -- that's a prime directive 
for a DBMS. The article explained other features that enterprise 
developers look for in an SQL platform:


    ... mission-critical applications require features such as intrinsic 
    security, transaction journaling, concurrency controls and the ability 
    to enforce data integrity constraints. Without those features, you 
    do not have secure, robust databases. Connecting a database to a 
    Web server adds other requirements, such as a multithreaded architecture 
    and the ability to do database backups without taking the server 
    down.


    Freeware and PC DBMSs are suitable for certain classes of applications, 
    but not for high-volume Web sites and mission-critical databases. 
    In any case, don't bet your business, or lives, on such software 
    unless you have the source code and the expertise to understand and 
    repair it.


Since that article appeared in print, improvements to MySQL have 
removed the "not ready for prime time" label. Features described 
in that article are now available to MySQL users:

    * transactions
    * concurrency control, locking, SQL standard isolation levels
    * intrinsic security
    * integrity constraints
    * thread-based memory allocation.

  TII Computer Deals at Dell Home Systems 180x150
	


MySQL uses separate threads to handle TCP/IP and named pipes connections, 
authentication, signaling, alarms and replication. The combination 
of threaded architecture and MySQL clustering provides powerful parallel 
processing capabilities. MySQL can process transactions in parallel 
with separate connections on separate processors using separate threads.
MySQL Milestones


A decade of development has moved MySQL out of the bare-bones DBMS 
category, enlarged its user base, and turned MySQL AB into a profitable 
company. One of the important milestones was integration of the InnoDB 
engine with MySQL 4.0. That upgrade gave MySQL multiple tablespaces, 
tables greater than 4GB and support for transaction processing. Other 
enhancements included OpenGIS spatial data types and hot backups. 
The latter enables a DBA to perform a backup without taking the DBMS 
offline. Hot backup software is available as a commercial add-on 
for databases using the InnoDB storage engine. 


MySQL 5.0, the newest version, is a major milestone. There have been 
enhancements to the tool sets, storage engines, types and metadata. 
 MySQL 5.0 includes features enterprise developers have come to expect 
from commercial SQL products. 

    * capacity for very large databases
    * stored procedures
    * triggers
    * named-updateable views
    * server-side cursors
    * type enhancements
    * standards-compliant metadata (INFORMATION_SCHEMA)
    * XA-style distributed transactions
    * hot backups.


MySQL has a demonstrated capacity for managing very large databases. 
Mytrix, Inc. maintains an extensive collection of Internet statistics 
in a one terabyte (1 TB) data warehouse that contains 20 billion 
rows of data. Sabre Holdings runs the oldest and largest online travel 
reservation system. It replicates 10-60 gigabytes per day from its 
master database to a MySQL server farm. The MySQL databases are used 
to support a shopping application that can accommodate a million 
fare changes per day."

Well, a couple of months ago .. so expect to see Firebird like syntax 
appearing in future versions of mysql.

Jim Starkey Sells Netfrastructure to MySQL AB and Moves On

 Today Jim Starkey, who led the original Vulcan fork of Firebird, 
 announced that he has sold his Netfrastructure web software business 
 to MySQL AB and will be taking up a full-time job as a developer 
 for the MySQL company.

Jim won't be a regular code contributor around Firebird any more, 
but he has promised he'll still be around to post the occasional 
"wolf-gram" in Firebird-Architect.

We in the Firebird Project wish Jim all the best for what looks like 
an interesting turn in his career.

seems to be a problem in my end

Yeah, kind of spooky without a head, though :)

Gaining root access to a Mac is 'easy pickings', according to an 
individual who won an OS X hacking challenge last month by gaining 
root control of a machine using an unpublished security vulnerability. 
On February 22, a Sweden-based Mac enthusiast set his Mac Mini as 
a server and invited hackers to break through the computer's security 
and gain root control, which would allow the attacker to take charge 
of the computer and delete files and folders or install applications. 
Within hours of going live, the 'rm-my-mac' competition was over. 
The challenger posted this message on his Web site: "This sucks. 
Six hours later this poor little Mac was owned and this page got 
defaced".

Pekr: do u have a URL for that article?

Yes Obsd has a very nice qualification scheme..and Im very happy 
with it ;-)

MVS is called Z/OS these days.

Hard to hack -- but then not many people wouid have the skills to 
even get started: the concepts are so different to what you'd expect 
from a PC or UNIX background.
But not impossible

That Mac article (from MS-owned ZDnet) has been widely discredited. 
From a follow up article on OSnews:


The ZDnet article, and almost all of the coverage of it, failed to 
mention a very critical point: anyone who wished it was given a local 
account on the machine (which could be accessed via ssh).


Original ZDnet article: http://www.zdnet.com.au/news/security/soa/Mac_OS_X_hacked_in_less_than_30_minutes/0,2000061744,39241748,00.htm
Follow up challenge: http://test.doit.wisc.edu/

The story is now finsished http://test.doit.wisc.edu/with a positive 
result...the Mac was not hacked ;-)

That was a new hack attempt btw...

Today I was just confronted with a 1 minute hack on VMS ;-) ..but 
that was a local account issue too :-) Still is fnu sometimes..

Dvorak is a web 1.0 dinosaur.

Devorak is a dinosaur.

They said they where worried about the bandwidth. seems that is the 
only thing which can stop a mac. :)

they don't have a BIOS

Blood v0.1.1 released to rebol.org.


the first ever public demo of how to use liquid.  The application 
itself is very simple for now, but the code is pretty clean, has 
a lot of comments to explain a lot of what is going on.

I've not had a chance to play with it yet, Max.

I suspect many of the downloads will be bots that like to index new 
content.....Not people passing by to check the scripts. New/changed 
scripts get prominent home page billing, so the bots come flocking 
to feast.

To some extent, yes. We do record counts of "likely human views" 
vs "likely bot views" -- but the stat you see is the sum of the two. 
And the division is not perfect by any means.

I'll slightly reverse my previous statement......The "download this 
script" link is protected by a HTML attribute "rel=nofollow". That 
should prevent well-behaved bots from following the link. So the 
count of downloads is likely to to human rich.

could be nice to see them separate, maybe by adding a "probable bot 
%" next to the counts   :-)

I have a newer version which has the "ability modifiers" added as 
extra labels to the right of the abilites... it took me 5 minutes 
to do, and it only needs one new simple !plug derivative:

;- !ability-mod
!ability-mod: make !plug [
	valve: make valve [
		type: 'ability-mod
		;-----------------
		;-     process()
		;-----------------
		process: func [
			plug
			data
		][
			vin [{!ability-mod/process()}]
			plug/liquid: 0
			vprobe data
			if integer? data: pick data 1 [
				plug/liquid: to-integer (data - 11 / 2)
			]
			vout
		]
	]
]


and necessary linkage within the !character setup, and appropriate 
faces in the window layout.

currently preparing 2 liquid modules for distribution on rebol.org 
:
  * LIQUID-VID : adding liquid functionality to ANY vid face

  * GLUE : a (hopefully growing) set of reusable core !plug classes 
   (like !sum and !subtract, in blood example).

Well, I just got home from work.  I'm cooking some dinner which I 
will eat while watching last night's episode of Battlestar Galactica 
and then I will download Blood and play with it a bit.

just thought I'd share this list I built while coaching someone in 
using liquid last night...

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

adding a substantial feature to liquid.  the ability to "freeze" 
nodes.  the nice thing is that the freeze state can be set as a function... 
so a node could potentially disactivate itself on the fly, when it 
detects some impending error is about to occur.


it can also stay dead until its dependencies are sufficient... making 
it a highly efficient at preventing useless processing until all 
its dependencies are linked up.

you could even cause its to process only after a time lapse occured... 
automatically preventing useless processing within live animation 
nodes  :-)

So I'm trying to create a plug, !color, that simply forces it's content 
to be a tuple, here's what I thought would work:

!color: make !plug [
	stainless?: true
	valve: make valve [
		type: 'color
		;-----------------
		;-     process()
		;-----------------
		process: func [
			plug
			data
			/value ; faster than:  /local value  
		][
			vin [{!color/process()}]
			plug/liquid: 0.0.0
			unless empty? data [
				if tuple? data/1 plug/liquid: data/1
			]
			vout
		]
	]
]

c: liquify/piped !color
fill c  255.255.255
fill c [0 0 0]



at this point c's content should be 255.255.255 not [0 0 0] which 
it is.

one note...  you might want to wait for me to release liquid-vid 
and glue... they will both simplify coding of things a lot.  and 
liquid-vid will even have a few dynamically adjusting faces like 
row and column.


funny thing is that its taking me far less energy (and code) to implement 
more dynamic and smart faces than glayout so far.  its also taking 
a lot less code to do a lot of the same things in glayout.

rule # 7


once you piped the color, processing is by passed.  this is a philosophical 
design decision.

pipes and containers are like storage.  their value is to be used 
as-is.  if you wanted to clean ANOTHER plug to a color, your code 
is correct

btw, I am now building up a series of sample files for use as a tutorial 
as you guys ask questions and post examples.  so from now on, most 
of the question will be compiled into a great collection, used for 
an eventual tutorial!


so keep the questions comming.  independent and explicit code examples 
like the above are excellent.

ammon in the above, the /piped is superfluous  ( and in fact a waste, 
since the p plug only needs to contain data)

sorry that is a BUG in liquid! hahahaha discovered it last night... 
well at 5am before I went to power nap.

its fixed and I wonder when that bug got inserted in the first place. 
 there is another tiny bug which I squashed, which was added with 
a brand-new (and not very teste) feature .

my bad. give me a second... I will upload v0.7.1

ok, verified that the freeze extension works properly with blood, 
so its a valid release for now.

will also make sure that my reply to your original question (built 
a little example in my tutorial folder) also is functional

!color: make !plug [
	valve: make valve [
		type: 'color
		;-----------------
		;-     process()
		;-----------------
		purify: func [
			plug
		][
			vin [{!color/purify()}]
			if integer? plug/liquid [
				; convert integer to b/w gradient
				plug/liquid: to-tuple head insert/dup copy [] plug/liquid 3
			]
			unless tuple? plug/liquid [
				plug/liquid: 0.0.0
			]
			vout

   ; this is ESSENTIAL determines if plug is dirty or not... basically

   ; if you return false, the node stays dirty... and is re-evaluated 
   everytime.
			; if you forget to return a value, liquid causes an error. 
			true
		]
	]
]

print "----"
c: liquify !color
fill c  255.255.255
probe content c
fill c  none
probe content c
fill c  11
probe content c

p: liquify !plug
link/reset c p 

; /reset is used to reset the state of the plug as 
; virgin plug before linking. (all links removed, 
; pipes and containers are forgotten/ignored)
; if /reset isn't used, the plug c WILL be linked
; but its links are ignored, since the plug is 
fill p 55



output:

255.255.255
0.0.0
11.11.11
55.55.55

Yes, my code is working but it's capable of a bit more than that...

Yes, I understand it.   I'll be modifying my code to use both process() 
and purify() as I'm currently capable of linking multiple plugs to 
!color to set r.g.b separately and I need process for that but purify 
to ensure I have a tuple.

btw adding node freezing, a very fundamental change to the engine, 
took  a huge 4 lines and about 40 bytes to implement!

announcing stream !  I am in the midst of  adding some more functionality 
to liquid which allows it to act as a signal processor (push method 
data-flow) the nice thing is that its incorporated  in the same plug, 
again, and using message stream will retain 100% compatibility with 
all the current plug featureset.

this will allow us to use window events directly within a lazy computing 
environment, for example, or provide dependency notification of child 
to parent changes.  this will allows a node to send a manual signal 
"downstream" and possibly take processing/setup decisions based on 
those messages.  downstream nodes should be able to return data in 
order to feedback the effects of the signal to its author, which 
might then, also activate some code.

so for liquid, this means a processing decision can be based on downstream 
nodes capability to handle it,  its like look-ahead processing

Max, you should take a look at petri-nets. I'm sure it will give 
you a lot of inspiration.

And I'm building up a lot of code and information for creating tutorials 
 :-)

I'm finding myself writing standard test code for each plug type 
as I go along and I was just thinking it would be nice if I could 
add the code as a block on the plug such that I could test any plug 
type by calling 

liquify/test !plug


Or something like that...  Could be a nice documentation/usage example 
feature.

that is a Tremedous idea.  I even know how It could be done... be 
carefull I might put you in charge of developping it   :-)

As you know, I just totaly reviewed how liquid-vid will handle its 
layout (now a live prodecural network in its own), so I am hard at 
work building that, but I will definitely put some time on integrated 
unit testing, when I rebuild the visual graph editor.  its such a 
great idea, as we have discussed, the I/O aspect of plugs cannot 
be ignored in dataflow, so this would be a great way to profile, 
document and verify expected node behaviour.

BTW...  I seem to be seeing a node processing it's liquid when it 
shouldn't be.  Once a node is liquified, filled and purified it shouldn't 
call process() or purify() again until it is filled again, should 
it?

btw there is already a plug/valve/stats feature embedded within, 
which gives you the node's current state and setup.

(content is a duplicate word for the cleanup function)

i don't know a part from you forgetting to liquify the plug first 
what could be going on!

that's a class... not an instance.

LOL, fix blood.r then, please!


; this is ESSENTIAL determines if plug is dirty or not... basically

; if you return false, the node stays dirty... and is re-evaluated 
everytime.
; if you forget to return a value, liquid causes an error. 
true

anyone who wants to get to use liquid, don't hesitate to try and 
ask stupid questions.  They are hard to answer, and its giving me 
a chance to get a general feeling of what needs more attention in 
the forthcomming revision to the whole liquid documentation.

for the layout algorythm,  I actualy did a complete flow analysis 
of a row/column resizing liquid graph.  its actually rather simple, 
when you force yourself to follow what data goes where.  note that 
I was able to build this without creating a processing cycle... which 
is neat, since some values are going to the parent face and coming 
back to its pane elements.

when you pipe two or more nodes together (using pipe() on a plug, 
using the /piped refinement of liquify, or fill/pipe) the system 
automatically creates a pipe server which acts as a broker amongst 
all piped plugs.

this is a normal plug to which all plugs are linked, via the pipe? 
attribute.

Ok...  So, what's the difference between a pipe and a link? >;)

linked nodes will ask their "subordinates" about their values... 
this starts a recursive chain reaction, until all subordinates of 
all subordinates have cleaned up.

plugs may be filled with data directly.  when you do this the node 
becomes a container, and this effectively turns off all of the linking 
management..

your plug simply stores a value and returns  it (but purify IS still 
called on it)

pipes work in about the same way, but every time a value is filled 
within a piped plug, ALL of the other members of that pipe ALSO get 
filled with the same value.

the pipe server thus serves as an in-between.  the fact that its 
also a plug makes it very flexible, since you can call the purify 
function on it.

note that you can LINK the pipe server and set it to a linked-container? 
 too! but that is advanced usage.

note that when you fill a pipe server through a node... even that 
node receives the data back.

the pipe server can be used to normalise the data into its purest 
form, and allows many things in your application to interact with 
it as peers.  one can be a string another an int.  but for each pipe 
client, they could care less about who and what the others are.  
they just need to know that, in this case, they are always receiving 
an int, and can convert it back to the format they need.

I know have a pretty good idea of recurring topics.

Ok.  I think I'm starting to see what you are doing with pipes.  
Some of the voodoo in Blood.r isn't as mystical as it was a few minutes 
ago. ;-)

a subtle but extremely powerfull and explicit demonstration of dataflow 
robustness.

glue now has a plug that returns gfx text size given any value and 
a font  :-)

-------------------------------------------------
NOTE:  

FROM NOW ON, 

every usable !plug definition that I post will be in black, to make 
it easy to differentiate from test code, and copy in your own libs.

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

	;-     glue-proc-face:
	glue-proc-face: make face [size: 100x100] 

	;-----------------
	;- !gfx-text-area
	;-----------------

 ; this class returns the area which a value, when represented as 
 a string, occupies.
	;
	; returns: a pair representing width and height
	;
	; usage:

 ;  linked only, unlabeled.  (filling this node will permanently freeze 
 it)
	;
	; inputs:
	; (1) [any!] value
	;     the first input is formed to a string, or set to ""
	;   	
	; (2) [object!:font] font to use

 ;     the test will be run with this font, irrelevant of what font 
 is currently set in the face.
	;
	; <TO DO>: add explicit support for /para facet
	;-----------------
	!gfx-text-area: make !plug [
		liquid: 0x0
		
		;-----------------
		;-    frozen?()
		;-----------------
		; plug won't do anything until you have proper linkage done.
		;-----------------
		frozen?: func [
		][
			vin ["" self/valve/type {/frozen?()}]
			vout
			(2 <> length? subordinates)
		]

		valve: make valve [
			;-----------------
			;-    process()
			;-----------------
			process: func [
				plug
				data
			][
				vin ["" self/valve/type {/process()}]
				plug/liquid: 0x0
				glue-proc-face/font: data/2
				glue-proc-face/size: 1000x1000
				glue-proc-face/text: any [
					attempt [to-string data/1]
					""
				]
				plug/liquid: size-text glue-proc-face
				
				vout
			]
			
			
		
		]
	]

Heh.  A bit simpler than the approach I was going to take, that is, 
if it does what you say it does... =D

Is there a way to hook into the attach function?  I want to build 
a pipe-server that handles multiple values but I want to be able 
to hook up the input plugs in any order and in some cases not have 
a plug for any given value.  To accomplish this I want to create 
a block that tells me which order the plugs are connected in so that 
I can use the index to select the correct plug from the server's 
liquid.

this may be a wild guess, but doesn't the !plug/subordinates do that? 
  I haven't been using pipes so much as links, but I would guess 
you would look at that, and I'd assume the plugs are in the order 
that they have been attached.  Maxim of course will correct me if 
I'm wrong.