AltME groups: search

its happened often yes.  less lately, since I'm dealing more with 
XML and less with raw data.

The biggest problem would be the different datatypes for different 
versions of SQL Server, if there is no good documentation for the 
native format. But BCP does the job quite well. I CALL it when necessary 
and try to FIND if any error output. 

There is XML format files as well, easier to understand but no functional 
differencies betwenn non-XML format files.

Steeve, sorry, it's a small hack. I grabbed the svg coords from inkscape 
manually and simply pasted them in a text file, made them pretty 
for rebol and converted them to DRAW in a simple way. I have no XML 
parser or anything like that.

I think not, older brosers only have xmlhttp (ajax) option, iframes 
and other comet like tricks but they can't do a socket .. I haven't 
seen what js.io does.. if you wanted to make a "pure" html chat without 
comet or polling you made JS that talked to invisible 1px flash and 
flash has XMLSocket or something like that. But I heard recently 
that it can be used for other things than xml ..

yeah last word often gets cut on shorter strings .. need to get xml 
via https:// POST working for a solution.

Florin, Gabriele wrote a templating engine based on XML ID attributes 
several years ago. It's called Temple

Is it possible for Cheyenne to support SVG?
I tried:
response/buffer: {<svg></svg>}
response/set-header 'Content-type "image/svg+xml" 


but failed.   double string was returned. "<svg></svg><svg></svg>"

You're using a literal string as response, you should try to add 
a COPY in front of it to avoid side-effects: response/buffer: copy 
{<svg></svg>}. Even better, as you're in a templating system, make 
it a template:

<% response/set-header 'Content-type "image/svg+xml" %>
<svg></svg>

ok, so I promised a little announcement about work I have been doing 
in/with/for cheyenne...

I have built a web service module (mod) for cheyenne.
  -----------------------
  features/highlights
  -----------------------

   * extremely fine tuned to cause the least cpu hit on the server process 
   since ALL processing is done in worker processes.

   * it uses an arbitrary number of rebol script files which you assign 
   to any host in the config file. (even the default)

   * once assigned, these files are compiled dynamically (as one app) 
   by the mod and are exposed via http by the server.

   * only the functions you *chose* are *ever* visible on the web, allowing 
   you to include support libs, data and function right in your server-side 
   api.

   * no direct execution of code occurs, *ever* from the client to the 
   server, all input is marshaled, and parameters are typed to your 
   function specs.

   * allows ANY type of web api to be delivered, from REST to SOAP like 
   interfaces.

   * output is programmable, so that you can output AS  json, xml, html, 
   txt, etc.

   * interface is also programmable, so that you can provide GET params, 
   POST forms, POST (XML, JSON, REBOL native data)

   * Automatic API documentation via source scanning and function help 
   strings .  there will also be some form of comments which will be 
   used by documentation.

   * No suport for sessions. this is part of your application layer, 
   which should use https and session keys in the submitted data, if 
   you require it.

   * it takes litterally 5 minutes to convert your internal rebol code 
   into web services which obey internet standards.

   * System is auto-reconfiguring... i.e.  you don't need to close cheyenne 
   to update the service, just restart the workers.

so, when will this be available?


*very soon*  I am building my first test release for my client tonight.


most of the research and prototyping is done, I already did some 
client demos for the people who are funding this project and I'm 
now in the "delivery" phase.


The most complicated parts of the system are already working (i.e. 
handler processes, dynamic compilation, automatic api interface building, 
per-host api/config, request/response chain of command, multi-format 
output, and more.)

a lot of details are still "up in the air" as far as implementation 
goes, so if you really have a need for this, PLEASE STAND UP and 
raise your voice.  tell me what you need, how you want it to work, 
etc.

so far I plan to deliver the first release with: 

  support 4 interfaces for calling : GET url, POST XML, POST Form data, 
  POST JSON.

  support 4 output formats : XML, HTML, JSON, TXT (which is in fact 
  rebol native data)


obviously this will be an ongoing project and anyone who is interested 
in helping out is welcomed to do so.  :-)

because the system actually self-identifies its available interface, 
we could even generate the SOAP xml schemas automatically, as in, 
totally dynamically.

yeah, but you still have to put the code behind.   the web-api mod, 
provides an interface automatically based on what is actually being 
served.  you could easily build a little WSDL to REBOL api file converter. 
 just load the XML, extract the methods, the parameters and build 
an equivalent rebol function stub.


Then all you'd have to do is implement the function body....  the 
only detail is the xml datatype which don't all map 1:1 within rebol, 
but that can usually be pretty well cornered within the code itself.

the module handler is pretty fast, considering, we are using external 
code and user hooks to setup the process.

calling this url on my meagre 1.5core2 duo
	http://localhost:81/echo.xml?value=tadam

returns this xml


<result status="success" method="echo" time-delta="0:00:00.000723302" 
phase="format-response">
    <echo value="tadam"/>
</result>

wrt api server speed  adding up all the required cheyenne server 
handling and tcp xfer we get:


>> s: chrono-time    read http://localhost:81/echo.xml?value=tadam 
     difference chrono-time s
connecting to: localhost
== 0:00:00.010442948

but yes, the question is what is the best way to determine the JSON 
mode (or XML or CSV or ...)

Bad news for websocket support in REBOL: the new RFC requires that 
client encodes data sent to server using a basic XOR encryption algorithm:


http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.3


This is a bad news for us, because it requires to process all bytes 
received, one by one to decode the message. REBOL is very slow at 
processing big data in loops, so the overhead can be very significant 
for data frames of a few dozen KB and more. It could affect Cheyenne 
global performances drastically.


However, it could have been worse, this encryption scheme is not 
required for data sent by server. So, as long as clients are sending 
small messages (up to a few KB), the overhead should be low. Fortunately, 
the usual client messages are queries to obtain data, so usually 
small. But if you have to move big amouts of data (like XML documents) 
back and forth through websockets, Cheyenne won't be able to cop 
with the load and it will most probably be a show-stopper.

I think you'll find it here http://www.rebol.org/view-script.r?script=xml-parse.r&sid=ij461ww

Something along the lines of the xml-odbc server that Easysoft sells 
.. but native and not odbc.

This waits for incoming xml requests and sends data back

Maxim, well, not too literate... or it gets in the way and starts 
looking like XML.

rdf is to xml what War and Peace is to Cat in the Hat -- Triples 
are working even with Maxim's code above (just not in hashes for 
more than a query with a single value).. but i crave the speed of 
index? against large datasets.

One of the issues with AWS is all the XML .. but I think we don't 
need a fancy XML parser .. .as it's pretty basic stuff.

payload: create-sdb-message "ListDomains" listDomains 10


result: to-string write http://sdb.amazonaws.comcompose [ POST [ 
Content-Type: {text/xml; charset="utf-8"} SOAPaction: "ListDomains"] 
(payload) ]

What would be nice would be a small tight library for dealing with 
basic XML

Start with simple, well-formed XML, and go from there.

Maybe what should happen instead is that if you receive other than 
xml, text, then the data should be streamed a file and a file! returned 
instead ( like Cheyenne does with html uploads ) ...

Do we have any xml helper functions?  


eg.  enclose-tag: func [ tag name ][ ajoin [ to-tag tag name to-tag 
join "/" tag ]]

i don't find parse-xml in r3 !!!! why ?

Perhaps Carl has not had time to test it under R3, so it is not properly 
certified.


Superficially, parse-xml seems to work under R3......If you had the 
time to do some more comprehensive testing, that may encourage Carl 
to make it part of the official release.

To export parse-xml from R2 and import it to R3:

In an R2 session: [r3-path] is the path to your r3 executable

    save %[r3-path]/xml-language.r join "xml-language: " mold xml-language

    save %[r3-path]/parse-xml.r    join "parse-xml: "    mold :parse-xml

In an R3 session:
    do load %xml-language.r
    do load %parse-xml.r

Claude, the R2 mezzanine source, including PARSE-XML, is in DevBase 
(aka R3 chat). It shouldn't be too difficult to adapt it to R3, for 
a library module. It would probably be a bad idea to include it in 
R3 as mezzanine though: History has shown that most people don't 
need to parse XML, and the ones who do usually need to parse XML 
differently from how PARSE-XML does so, and differently from each 
other as well. This kind of situation is what the module system and 
community libraries are for :)

I have a XML file and want to handle it by tags like a nested block. 
Are there are any tricks? Or do I need to use PARSE / FIND etc.

parsed XML

What I mean is, do you want to convert the XML to a block and then 
access it like this?

  data/tag

Or do you just want to parse the raw data out of the XML between 
those two <tags>?

This was used with small pieces of XML, rather than entire documents, 
but might be a starting point for you.


xml-get-field: func [input name /local xml-field= data other-name] 
[
	xml-field=: compose/deep [ 
		some [

   (rejoin ["<" name ">"]) copy data to (rejoin ["</" name ">"]) to 
   end
			| skip ;(to paren! [prin '.])
		]
	]
	either parse input xml-field= [data] [none]
]

I've used Gavin's XML-object.r in a couple of projects. Not tried 
it under R3 though:
   http://www.rebol.org/view-script.r?script=xml-object.r

; Another flavour of Rebol XML:
do http://www.ross-gill.com/r/r3xml.r
doc: load-xml/dom location
foreach tag doc/get-by-tag <a> [
	probe tag/flatten
	probe tag/text
	probe tag/get #href
]

Decode loads an XML document?

r3xml is an R3 port of AltXML, a Rebolised version of XML DOM: http://bit.ly/XMLandREBOL

There is a bug in R3, which will be very difficult to find... I was 
parsing very large XML files and have got invalid chars in the result. 
I cannot reproduce it unfortunatelly.

That sounds both very worrying and a challenge - how big were the 
XML files? Were they utf-8 encoded? Did you verify the utf-8 encoding 
in the XML or could it have contained invalid utf-8 sequences?

especially in xml u might have a lot of attributes.. makes sense 
to break them into lines, doesn't it?

So, as our needs became more complex (esp. because of the initial, 
never released version of the wiki editor), I had to change approach. 
Also, at that time Maarten was doing the S3 stuff and needed a XML 
parser as well.


So, first, the Filter was split up into three modules. The first 
is the parser, that takes a HTML or XML string and just sends "events" 
to a callback function. This can be used basically for anything. 
(Maarten never used it in the end.) The second part was the first 
FSM, the HTML normalizer. You'll still find it within the Power Mezz, 
but it's deprecated. The third part was the actual filter and regenerator 
(second FSM). You can find it in the repository history.

maxim - regarding namespaces: Are you kidding? I'm not even going 
to touch those. My excuse is if xml-object.r can't handle it, neither 
will I. :^(

Actually, I think a pre is closer to heredoc than CDATA.
CDATA is strictly speaking for XML or XHTML. not HTML.

And CDATA only, in effect, protects unescaped <, > and & from being 
interpreted as mark-up.

Perhaps, more importantly for the heredoc issue, whitespace is not 
guaranteed to be left as-is in CDATA:
   http://www.w3.org/TR/html4/types.html#h-6.2
But it certainly does not matter to me what we call it :)

The reason for this is I am converting deeply nested xml into rebol 
objects and I don't know what the final object will turn out to be 
....

Graham, did you figure out the object issues? And are you using or 
have you tried the xml-object.r script?

XML to objects from SUnday

Is there a trick / limit to just how deep one can create an object 
which itself has nested objects stored in a block? I have this xml 
string that I converted to a block via parse-xml but at about two 
levels in, it remains a block (make object!...)

Or try Gavin's code:
   http://www.rebol.org/view-script.r?script=xml-object.r

I'm using this one http://www.rebol.org/view-script.r?script=xml-parse.r

Yes, I am using xml-parse and then xml-object. My question is something 
that I have dealing with for a long time actually. So is there a 
limit to how far something is reduced in terms of nesting?

Sorry, about these delays. I was on on an online session.
So When I  use parse-xml+  on my xml string, I get the following:
[document [version none
        encoding none
        standalone none
        doctype none
        pubid none
        sysid none
        subset none

    ] [["TTL_Status" none ["^/^-" ["INPUT_TTLS" none ["^/^-^-" ["TTL_IN" 
    ["value" "0"] [{

^-^-^-} ["status" ["value" "1"] none] "^/^-^-"]] "^/^-^-" ["TTL_IN" 
["value" "1"] [{

^-^-^-} ["status" ["value" "1"] none] "^/^-^-"]] "^/^-"]] "^/^-" 
["OUTPUT_TTLS" none ["^/^-^-" ["TTL_OUT" ["value" "0"] [{

^-^-^-} ["status" ["value" "0"] none] "^/^-^-"]] "^/^-"]] "^/"]]]]

I know it's not that readable...

Then I run xml-to-object on that block and get:

o: xml-to-object  blk
where block is the output of parse-xml+ above.

probe o


[document: make object! [TTL_Status: make object! [INPUT_TTLS: make 
object! [TTL_IN: make block! reduce [

                    make object! [status: make object! [value?: "" value: "1"] value: 
                    "0"] make object! [status: make object! [value?: "" value
: "1"] value: "1"]

                ]] OUTPUT_TTLS: make object! [TTL_OUT: make object! [status: make 
                object! [value?: "" value: "0"] value: "0"]]] version: none
        encoding: none
        standalone: none
        doctype: none
        pubid: none
        sysid: none
        subset: none
    ]]


So this is where my ignorance leaves me. How do I make "o" into a 
an object where all the nested objects become real objects and don't 
remain as blocks?

I think this is a Graham question. I've been trying to communicate 
with this video encoder. It uses .xml and .cgi files to talk to it:
tmp: http-tools http://192.168.1.62/user/GetTTLStatus.xml[]
and this works fine.


The problem is with he .cgi files. They aren't POST files but they 
only return 

 a: http-tools http://192.168.1.62/user/StorageMediaFiles.cgi[] probe 
 a
make object! [
    HTTP-Response: "<?xml version='1.0' encoding='ISO-8859-1' ?>"
    Date: none
    Server: none
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: none
    Content-Length: none
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
]
When you place the url in a browser it works as expected. 
Any ideas on how to get this to work?

And you're right, there is probably something else going on. I am 
at least getting part of the message. A successful .xml call looks 
like this:

a: http-tools http://192.168.1.62/user/StorageEventMode.xml[] probe 
a
make object! [
    HTTP-Response: "HTTP/1.1 200 OK"
    Date: none
    Server: "Mango DSP - HTTP Server (v2.34)"
    Last-Modified: none
    Accept-Ranges: none
    Content-Encoding: none
    Content-Type: "text/xml"
    Content-Length: "270"
    Location: none
    Expires: none
    Referer: none
    Connection: none
    Set-Cookie: none
    Cache-Control: "no-store"
    content: {<?xml version="1.0" encoding="ISO-8859-1" ?>
<?xml-stylesheet type="text/xsl" href="StorageEventMode.xsl"?>
<StorageEventMode>
^-<RecOnNetworkFailure id="RecOnNetworkFailure" checked="true"/>
^-<PreEventBufferTime id="PreEventBufferTime" value="20"/>
</StorageEventMode>
}
]

So what's happening is that the server is not returning an LF/CR 
to separate the contents from response fields so when it gets to 
 parse-header, that function does not know there is any contents. 
In stead of getthing something like:

HTTP-Response: HTTP/1.1 200 OK
Server: Mango DSP - HTTP Server (v2.34)
Content-Type: 
text/xml
Content-Length: 270
Cache-Control: no-store

<?xml version=
1.0" encoding="ISO-8859-1" ?>"

I am getting:

HTTP-Response: <?xml version='1.0' encoding='ISO-8859-1' ?>
<?xml-stylesheet type='text/xsl' href='StorageMediaFiles.xsl'?>
<StorageMediaFiles>
<MediaFile ..."


Placing a LF between the first and second lines fixes it. I am going 
to kludge it for now since I know what routines work and don't.

if you include schema validation... I'd say XML is a nightmare  :-)

XML is some of the simplest to parse, and I guess schema too.

XML schema validation process is an 80 page document guide and 80 
page reference.  it isn't quite as easy as the xml it is stored in.

XML and HTML are relatively easy to lex, and require Unicode support, 
so hand-written lexers are probably best. Schema validation is a 
diffferent issue.

I just finished clening up my public xml library for Graham to test... 
if all goes well, I will proably upload it to rebol.org this week.

ASLR: I suppose it's required, but I can't find any information from 
an official source explaining the exact requirement for ASLR on Windows 
(except the additional flag to set in the executable header).


While searching for that, I found this interesting reading about 
PIC: http://www.gentoo.org/proj/en/hardened/pic-internals.xml#doc_chap7

Yes, it makes things a step more dynamic, so you move some of the 
checking to runtime. But that's actually the point: you can then 
develop interfaces that can be loosely compatible with a time range 
of interface versions. It's the philosophy of static everything versus 
declarative everything in REBOL and XML. In the beginning of computing, 
static seemed more correct, but these days it has turned out that 
everything has to be able to withstand change as well as possible

GTK's, and other IDEs', idea has always been that Glade, and now 
a newer interface builder, makes it easier, but combining a generated 
XML interface definition manually with some code language doesn't 
compare to Red/System

Evgeniy, function calls are not really part of the syntax in REBOL, 
or Topaz and i think even Red/System. So, yes, it is a CFG, it's 
just not like other languages (more like XML or JSON).

I bet you didn't know tags where usable directly  ?  not many think 
about it, but since tags are strings, they make a lot of sense for 
representing XML tree structures... and indeed, I used them when 
I had namespaced tags.