World: r3wp

Both XML and REBOL already work on multiple systems, I don't perceive 
much of a speed increase, and now-a-days, Zip works great.  WE did 
not have that as a standard 20 years ago.

Here's a breakdown for any encoding (Pcode, XML, REBOL, whatever):

Portability:

You need to build or acquire a decoder or encoder, and third-party 
code would need to as well. Advantage: XML


Faster execution: The main way you get that is to make the model 
of your data format match your data model. If the match is close 
enough you can translate the data to your internal model in insignificant 
time, like EBML to XML, Rebin to REBOL, or CPU instructions. If your 
internal semantic model is simple enough you can quickly do a direct 
interpretation of the data, like older Pcode interpreters or the 
original Java byte code, or the micro-operations inside modern CPUs.


In the case of REBOL, we have it easy because REBOL is primarily 
a data model. All we have to do is encode that data in an efficient 
binary format and then decode that format to the memory model. That's 
Rebin, the proposed Pcode of REBOL.


In the case of XML, it is slightly more difficult because there are 
competing binary encodings, and none of those will be supported in 
a web browser until it wins the format war. EBML is like a Zip for 
the XML data model, rather than its syntax (similar compression algorithm 
too) - much faster than unzipping XML and parsing it. The main problem 
is that only Matroska decoders support it right now - no web browsers. 
Similar constraints exist for the other binary encodings of XML.


In the case of SVG, we are much less lucky. SVG has its own data 
model on top of the XML data model. Once you decode the XML from 
whatever format it was encoded in, you end up with data of the XML 
model - then you have to interpret that data to get a dataset in 
the SVG model, much like the relation between REBOL and the Draw 
dialect. There may be some advantage to coming up with a Pcode for 
SVG.


The main thing that you need to keep in mind is that your Postscript 
experience is throwing you off: The semantic models of modern graphic 
formats are declarative, not programmatic - this was the main change 
between Postscript and PDF. A Pcode for a modern graphic model would 
not be executed like code, it would be loaded as data.

R, I doubt that Adobe has any committment to SVG now.

Graham - but if SVG is W3C standard, everybody will use it, no matter 
what, no?

Shall we list for Pekr the W3C standards that are widely ignored 
or misimplemented by everyone?

Not all W3C standards though.

Is there any better body for submissions? If not W3C, web would not 
exist, as MS vs Netscape were each going their own route.

SVG is widely implemented by those who actually pay attention to 
standards. That does not include the companies behind the majority 
of the content on the web: Microsoft and Adobe.

By "behind" I mean "who set the standards for", sorry.

What does have Adobe to do with it? They don't have any web browser. 
As for MS, in EU Firefox is reaching 50%

Who cares for IE. If it would be for me, I would drop its support 
altogether. And yes, I am anti MS fanatic :-)

What does have Adobe to do with it?

 The majority of vector content on the web is either in Flash or PDF 
 format.

Flash and vectors? Blah .... Flash is slow junk, just used by everybody 
... Good for adverts, not apps ...

PDF is cool.

Adobe was supporting SVG before they bought Macromedia - now they 
have dropped SVG for Flash.

But you are right, Flash sucks for apps.

Please note that Adobe has announced that it will discontinue support 
for Adobe SVG Viewer on January 1, 2009.

AFAIK, Adobe has discontinued downloads of the SVG Viewer already 
:(

i JUST DOWNLOADED THE PLUG-IN

That's how I found the above quote

Clearly "AFAIK" isn't far enough :)

Interesting conversation on SVG ... perhaps it would be better to 
continue in the SVG Renderer group (or just rename it to SVG?) no?

IE needs the Adobe plugin to view SVG.  I believe but have not seen 
it working that FF has/were building their own viewer built in.

I don't agree, that "Flash is slow junk". It was very well designed 
for creating interactive animations. And it supports things, which 
SVG is missing... as for example possibility to cache vector drawing 
as a bitmap. If something is slow, in most cases it's not Macromedia's 
fault.

maybe it's not that slow, but still, Flash is junk

BrainH, I won't belabour the point, I'm simply still unclear how 
once can make REBOL really much faster by making byte-code from it. 
 But, perhaps someone will, and make a demo, and prove it to me in 
the future… I agree that Zip XML is not a solution, but unless the 
Pcode system for XML is built into the browser, I don't see an advantage 
there either yet.

I'll be the first to use both though, when they exist.

Ashley, yes, will move future SVG convo to group…

Rebolek: tell me why?

Reichart, Rebin won't make REBOL run faster internally, but it would 
improve the storage and transmittal of REBOL data, so things like 
/Services would be faster. Internally REBOL is already fast.

I know most people here are still treating SaaS as a red headed step 
child…but guys, it IS what is happening…  : )

Check this out:

http://code.google.com/apis/chart/#url_format


They got to it before Richard and I could complete ours, and given 
there license (don't worry about it if you use it less than 250K 
times a day!), we are probably just going to support it directly.


How about writing a REBOL interface that lets you test it first, 
then out puts Google compatible REST?


Even without Google Charts, it is a stand alone useful program, but 
WITH Google, it might get noticed by the public.


One should be able to whip this together quickly, and it would be 
a useful simple report component everyone could use.

that was released quite a while ago wasn't it?

I didn't think it could do time series ...so I didn't persue it.

It gets better, all the time...Google has a habit of that...

can't see that they do it yet

Point me to a graph on the web that looks like what you want.  I'm 
planning to use them, but clearly, there are things they don't do, 
and I plan to do that in REBOL, but use the same trick.

This is what I have at present.  https://www.compkarori.co.nz.. 
login as guest/1234 select results/laborator and click on any of 
the results to bring up a graph at the bottom of the page.

Cool stuff (wow, what a CAPTCHA! LOL)

So for example,

You want to hand it:

A range - 60 to 100 mmHg for example.
A bunch of data (dates with values)


I would have to study Google.Graphs, but it seems they allow this.

that's Nenad's captch library at work.

It's bundled with Cheyenne I think.

Most graphing programs aren't smart enough to deal with dates and 
values ....

most free ones ...

I had to write my own in postscript http://synapse-images.s3.amazonaws.com/73C55E9348E30B2419011E4D87DDCDCE.pdf

ie. I used Rebol to generate the postscript graphs

Just so I'm clear, what is missing from this: http://chart.apis.google.com/chart?cht=lc&chs=200x100&chd=s:frothsmzndyoteepngenfrothsmzndyoteepngen&chxt=x,y&chxl=0:|Apr|May|June|1:||50+Kb

Not sure what I'm seeing.  I get an endless wait.

There's a line graph with 3 months on the x-axis.

what I want to do is feed date data and let the graph program automatically 
generate the x-axis labels.

Hmmm....I'm not familiar with Google Graph yet enough to confirm.

But...this is another one of those areas we are starting to play 
with.  I really like thier basic method, although, SOAP might be 
nice so one can work in something more like XML

Does google expect you to supply the x-axis labels and spaces them 
evenly ?

That is what I was just studying...

This is what I am using now http://www.ejschart.com/