AltME groups: search

compose [<a href="/rest-cart/ordet/ (to-string session/id) "> "Bezahlen" 
</a>]

This is where persistent data structures come in. Based on the work 
of Phil Bagwell, Rich Hickey described how he used bit partitioned 
hash tries to make efficient "copies" of data structures, and this 
forms the basis of data storage within Clojure. Essentially all data 
is stored in a tree and when one makes a copy with a small change, 
one can create a tree with a new root and only the path to the changed 
item needs to be copied and modified. The rest of the tree's branches 
remain precisely the same. This significantly reduces the amount 
of copying that is required and makes multiple "versions" of a data 
structure entirely practical.

First cut QAD on join/rejoin, still about twice as fast the originals:

	join: make function! [
		"Concatenates values."
		value "Base value"
		rest "Value or block of values"
	][
		either series? value [
			make type? value reduce [value rest]
		][
			make string! reduce [value rest]
		]
	]


	rejoin: make function! [
		"Reduces and joins a block of values."
		block [block!] "Values to reduce and join"
	][
		either empty? block: reduce block [block] [

   make either series? first block [type? first block] [string!] block
		]

	]

if the first item is not found, it still searches all the rest which 
is no good

Done, I've submitted via PayPal :-)  Thanks for your help, I get 
can some rest now :-)  Thanks Maxim for your help also!

I'm getting a "REST method is not defined" response.

maybe some kind of REST header needs to be sent as well?

not an expert on REST interfaces... though I am using one with a 
server right now...

and then chokes.. im thinking it the rest header is lacking somehow.. 
but if it's asking for just xml, where would I shove it? I would 
think the rebol custom 'post' would do that.. but yeah, probably 
needs the Content-Type: "application/xml" .. ?

It's this kind of verbose nonsense that should have been left behind 
in the last century.

Some time ago, I did form-decimal function too. But I am really a 
coding lamer, so dunno, if it cover at least half the cases other 
versions do. Here it is:

form-decimal: func [num /local tmp main rest sign base][

     either found? find tmp: to-string num "E" [

              parse tmp [
                 [copy main to "." 
                  skip
                  copy rest to "E"
                  |
                  copy rest to "E"
                  (main: copy "")  
                  ]
             
                 skip
                 mark: (sign: copy/part mark 1)
                 skip
                 copy base to end
               ]


        either sign = "-" [

                tmp: copy "0."

                loop ((to-integer base) - 1) [insert tail tmp "0"]
                insert tail tmp rest
        ][
                tmp: copy ""

                insert tail tmp join main rest

                loop ((to-integer base) - (length? rest)) [insert tail tmp "0"]  
                    
                           
        ] 
     
      tmp                 

     ][num] 

]

amacleod - the fix is easy - just replace "insert tail tmp rest" 
by "insert tail tmp join main rest"

Graham, here's the issue: I have some vid objects such as ua-fname: 
field. They follow a pattern in that the "ua" stands for "User Add" 
and the rest corresponds to the actual field name in the DB. The 
function I am writing is created in a way to be very generic and 
knows how to handle an insert into the DB based on a few parameters. 
What I am looking for is a way to "create" a name by joining "ua-" 
and field name which refers to the actual vid gadget.

Much of the R2/Forward stuff has been incorporated into 2.7.7 already, 
and most of the rest (except maybe 3 functions) will be in 2.7.8.

Oh, it gets trickier (in theory - I've had to do a lot of scientific 
method on the internals, not decompiling). I think that DO does some 
of the function call work, and the function type itself does the 
rest through an internal action. DO handles the evaluation rules 
and builds the stack frame, then passes along that stack frame to 
the function dispatch action of the function type for it to redirect 
to the real code in a type-specific way.


Now it definitely works that way, the only question is whether the 
type-specific dispatch code is built into DO itself, accessed through 
the action dispatch mechanism, or action code called directly without 
going through the action dispatch mechanism. Only Carl or a decompiler 
could say for sure. But really, it doesn't matter because the behavior 
is the same in any case.

first one is result: find blk 23  .. but how to quickly find the 
rest
foreach is way too slow on blocks with large amounts of data

Ladislav, a clarification: The DED has a semantic model, but it doesn't 
exactly match the in-memory model. And there is currently no function 
that can generate a serialized form of the in-memory model, and no 
function that can recreate the in-memory model from a serialized 
form (in this case "serialized" being used in its accepted meaning 
rather than the REBOL "serialized syntax" term). MOLD and MOLD/all 
are just approximate, as is LOAD. DO is a bit more accurate, but 
there is no function that can generate DO code from *all* in-memory 
structures, just some of them; the rest currently have to be written 
manually. So what we need is a function that does a better job of 
serializing the in-memory data model, and probably a new syntax to 
represent it.

Report the observed difference and the expectation that this should 
not differ. The rest is up to whoever feels qualified to contribute 
more detailed observations and/or implementing a fix.

We are doing that is other ways, mostly by paring down the number 
of included-by-default non-native functions to just what the system 
needs, and putting the rest into optional utility modules. (I assume 
you were proposing this for R3, since R2 is in maintenance mode.) 
We are also encouraging this kind of thing to go into community libraries. 
However, there is currently a missing feature in R3 that makes mezzanine 
loop functions rather difficult to write (no RETURN or EXIT passthrough), 
so any added loop functions are *definitely* not going into the system 
until that is resolved.

not being able to use paths to access these datasets is quite annoying 
since we can practically do all the rest.

It comes to my mind that reduce/into should not behave like inserting 
data but changing them.

Changing data if it's it's at the end of the container will simply 
add them.

But if it's at the head of the container, it will remplace them intead.
Probably more usefull, than the current behavior.

so that 
>> reduce/into data data

would simply do the job we all expecting. To reuse the same block. 
A reduce in place (rest in a peace)

I've never had a need for reduce/into or unique/into. The optimizer 
in my brain says reduce/info could be useful, but the rest of my 
brain thinks the lure of possible optimizations will create internal 
strife with said optimizer. :-) I do have an /into refinment on my 
COLLECT func, and the standard COLLECT does as well, but my goal 
there was for convenience is building up results, not optimization.

Maxim - your glayout looks consistent, as buttons fit the rest. Current 
RebGUI buttons are a bit ... ehm, strange ...

Or, spend 10 mins learning how to use SVN and join the rest of us.

table: We have extended TABLE to allow horizontal scrolling. You 
specify the number of visible columns and the rest can be scrolled.

how so .. you type man and get 5 choices so save on typing all the 
rest ...

My main screen was ViD based as it used a toggle widget .. and then 
the rest was rebgui

sorry for the double-send.  and I realize that in cleaning up the 
code I left out the initial table load using the "tbldata" in the 
first window, but I think the rest of the sample represents my issue.

TIA for helping a newbie!

I haven't tried loading fonts in draw on Linux, but the rest of this 
works (the color is changed by the draw command "pen red"):

Rebol []
do %rebgui.r
font1: make face/font [
    ; name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
    size: 11
    style: [italic bold]
]
example: compose [
    font (font1)
    pen red
    text "Hello World!"
]
display "Example" [
    style 20x20 data [
        box snow 100x100 effect [
            draw example
        ] 
    ]
]
do-events

I prefer to have such discussions in R3 chat. Having them here means 
more work for me, since most of the rest of the crew that knows the 
internals doesn't come here, so it ends up being up to me to answer.

the rest of the crew
.. do you mean Carl or someone elseas well? :)

Yeah, it is much better to set names of semantic attributes that 
have associated colors in the theme, then let the theme pick the 
actual color that fits with the rest.

Gabriele, I know that R3 handles case-insensitiveness of Latin1 characters 
in Unicode text better than R2 with UTF-8, but beyond that I don't 
know. There is still some stuff to do relative to Unicode. The implications 
of Unicode support on the rest of the system are mostly implemented 
though, with the glaring exception of PARSE.

This is how I use R2-Forward safely at Qtask without changing the 
rest of the codebase, for instance.

but when R3 gets a bit more stable, most of the work done in R2 will 
go over R3.  I'll only have to recode one or two core libs for all 
the rest to function.

load: func [
	{Loads a file, URL, or string.}

 source [file! url! string! binary! block!] {Source or block of sources}

 /header  {Includes REBOL header object if present. Preempts /all.}

 /next    {Load the next value only. Return block with value and new 
 position.}

;	/library {Force file to be a dynamic library. (Command version)}
;	/markup  {Convert HTML and XML to a block of tags and strings.}
	/all     {Load all values. Does not evaluate REBOL header.}
	/unbound {Do not bind the block.}
	/local data content val rst tmp

][  ; Note: Avoid use of ALL and NEXT funcs, because of /all and 
/next options
	content: val: rst: tmp: none ; In case people call LOAD/local
	
	; Retrieve the script data
	data: case [
		block? source [ ; Load all in block
			return map x source [apply :load [:x header next all unbound]]
		]
		string? source [source] ; Will convert to binary! later
		binary? source [source]
		; Otherwise source is file or url
		'else [
			; See if a codec exists for this file type
			tmp: find find system/catalog/file-types suffix? source word!
			; Get the data, script required if /header
			content: read source  ; Must be a value, not unset
			case [
				binary? :content [content] ; Assumed script or decodable
				string? :content [content] ; Assumed script or decodable
				header [cause-error 'syntax 'no-header source]
				block? :content [content]
				'else [content: reduce [:content]]
			] ; Don't LOAD/header non-script data from urls and files.

  ] ; content is data if content doesn't need copying, or none if it 
  does
	]
	;print [1 "data type?" type? :data 'content true? :content]
	if string? :data [data: to-binary data] ; REBOL script is UTF-8

 assert/type [data [binary! block!] content [binary! string! block! 
 none!]]
	assert [any [binary? :data not header]]
	if tmp [ ; Use a codec if found earlier
		set/any 'data decode first tmp :data

  ; See if we can shortcut return the value, or fake a script if we 
  can't
		case [

   block? :data [if header [insert data val: make system/standard/script 
   []]]

   header [data: reduce [val: make system/standard/script [] :data]]

   (to logic! unbound) and not next [return :data] ; Shortcut return

   any [next any-block? :data any-word? :data] [data: reduce [:data]]
			'else [return :data] ; No binding needed, shortcut return
		]
		assert/type [data block!] ; If we get this far
	]
	;print [2 'data mold to-string :data]
	
	if binary? :data [ ; It's a script
		unless find [0 8] tmp: utf? data [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		; Process the header if necessary
		either any [header not all] [
			if tmp: script? data [data: tmp] ; Load script data
			; Check for a REBOL header
			set/any [val rst] transcode/only data
			unless case [
				:val = [rebol] [ ; Possible script-in-a-block
					set/any [val rst] transcode/next/error rst
					if block? :val [ ; Is script-in-a-block
						data: first transcode/next data
						rst: skip data 2
					] ; If true, val is header spec
				]
				:val = 'rebol [ ; Possible REBOL header
					set/any [val rst] transcode/next/error rst
					block? :val ; If true, val is header spec
				]
			] [ ; No REBOL header, use default
				val: [] rst: data
			]
			; val is the header spec block, rst the position afterwards

   assert/type [val block! rst [binary! block!] data [binary! block!]]
			assert [same? head data head rst]
			; Make the header object

   either val: attempt [construct/with :val system/standard/script] 
   [
				if (select val 'content) = true [
					val/content: any [:content copy source]
				]
			] [cause-error 'syntax 'no-header data]
			; val is correct header object! here, or you don't get here
			; Convert the rest of the data if necessary and not /next
			unless any [next block? data] [data: rst: to block! rst]
			if block? data [ ; Script-in-a-block or not /next
				case [

     header [change/part data val rst] ; Replace the header with the object

     not all [remove/part data rst]	; Remove the header from the data
				]
				rst: none ; Determined later
			]
		] [rst: data] ; /all and not /header
	]

 ; val is the header object or none, rst is the binary position after 
 or none

 assert/type [val [object! none!] rst [binary! none!] data [binary! 
 block!]]

 assert [any [none? rst same? head data head rst] any [val not header]]

 ;print [3 'val mold/all :val 'data mold/all :data "type?" type? :data]
	
	; LOAD/next or convert data to block - block either way
	assert [block? data: case [
		not next [ ; Not /next
			unless any [block? data not binary? rst] [data: to block! rst]
			data
		]
		; Otherwise /next

  block? data [reduce pick [[data] [first+ data data]] empty? data]
		header [reduce [val rst]] ; Already transcoded above
		binary? rst [transcode/next rst]
	]]
	
	; Bind to current global context if not a module
	unless any [ ; Note: NOT ANY instead of ALL because of /all
		unbound
		(select val 'type) = 'module
	][
		bind/new data system/contexts/current
	]
	;print [6 'data mold/all :data 'tmp mold/all :tmp]
	
	; If appropriate and possible, return singular data value
	unless any [
		all header next  ; /all /header /next
		empty? data
		1 < length? data
	][set/any 'data first data]
	;print [7 'data mold/all :data]
	
	:data
]

LOAD/header/next gives back [header-object [the rest of the code]]

since that's do the makes the rest of the work more easy to grow

SYSTEM/view is View settings - we'll have View modules too, in with 
the rest of the modules. We just haven't modularized the code yet 
- we needed to have modules first. The file-types setting is in system/options 
with the rest of the general system options.

Dialecting isn't any slower, it's just that everything else has gotten 
quicker in R3, and dialect processing just seems slower in comparison. 
Dialecting just has to catch up with the rest.

Steeve - your attitude is the same what DocKimbel showed here some 
two weeks ago. I thought that I am talking to adult ppl, and I really 
don't understand such childish behaviour. Such an attitude is treat 
to those, who try to actually do something. Do you really think that 
the rest of us would not like to have R3 available few years ago?

Henrik:<I can only emphasize the importance of submitting Curecode 
reports.>


If you look at some very recent bug reports (numbers 700 -- 799), 
over half of them have been resolved, often within days
    46 built and/or tested (ie fixed) 
     8 dismissed (not actual bugs)

There seems no better time to report R3 problems than now!


The rest are Reviewed, Deferred or Waiting.....So still on the action 
list.

That's why the only function creation function with a refinement 
is FUNCT - since it does so much work anyways that the refinement 
overhead is much lower in comparison to the rest of the code.

Pekr, MAP-EACH (using the new name) is used in LOAD to implement 
LOAD [%s1.r %s2.r ...]. I don't know how it is used in the rest of 
the mezzanines. I mostly use it in my own code, but the version I 
backported to R2 as a mezzanine.

There are a few serialized keywords, but the rest are constructors.

I've just finished helping the plumber install a new submersible 
pump in my 50 meter deep well, changed all the electricals too... 
I didn't have water for the last 4 days... 


now I can give myself a rare treat.  taking the rest of the day off 
today, so I can do my things.... and that includes one "fun" project... 
usually a short project that I've been putting off of a long time... 
today its liquid/R3  :-)

Sunanda, the reason it's not a bug is because for every iteration, 
'a is set to mold system, and mold system includes the previous value 
of 'a from the previous iteration, as a string. So that means that 
every iteration is the length of the rest of the system, plus the 
length of the previous 'a times the number of visible references 
to it. Since there are 4 visible references to the collection of 
global words, this means that the growth is exponential, and of a 
larger exponent than R2 (which has only one visible reference to 
the global words, so it just doubles).


The way to prevent the exponential growth is to assign none to 'a, 
or unset 'a, before you mold the system again.

The 4 visible references to the global words should be cut down to 
1 or 2 once the rest of the module system is done. The other 2 will 
refer to separate contexts than the current "global" context.

or using only one feature from a newer version of a library and all 
the rest from the older one, cause the update isn't compatible... 
that should be allowed.

One thing to remember is that simplicity is a real value here. We 
need to make sure that any features we add integrate well with the 
rest, and don't create a burden on the programmer. Any setting that 
you can make is a setting that you will have to decide whether you 
need to make, so that adds to the development overhead.

So I'm suggesting that the things that would normally be bound in 
an object spec get BIND/copy when you MAKE from an object prototype, 
but otherwise referenced. That means BIND/copy of blocks, words, 
functions and closures. The rest can be copied by the init spec if 
you need to, or not.

Or you can wait for the next version, and have EQUIV?, ==, !== and 
=? do 17-digit comparisons, and the rest do the 15-digit comparisons 
that make values like 0.1 work.

I think pretty soon. That got delayed because Ladislav and meijeru 
started being really thorough about reporting inconsistencies in 
the core semantics of the language, so we started working on resolving 
those in case any changes affect the rest of the system. For instance, 
the equality change includes changing the equality actions to natives, 
which changes the action list - that might affect plugins.

Datatype conversions: I think that once TO-HEX is removed for most 
datatypes the conversion issues of the TO-* set will be done. The 
rest will be handled by proper conversion functions, that we don't 
need to write immediately. We should probably wait on implementing 
those as natives until the APIs are worked out in REBOL versions, 
or plugin code. We can speed them up later once their behavior is 
agreed on.

Yeah, I found !=. I guess, the :<> is a lexical bug?

(I'm still working on a deep test on the lexical analyzer and hope 
to send the result to Carl and the rest of the R3 developers in the 
near future.)

Knowing the internals isn't hard. I haven't seen the native source 
- I've just seen the mezzanine source, followed the conversations, 
and read sites like the onee Ladislav linked above. The rest is deduction.

We'll see. Part of the reason for the release is to sync his work 
with the rest of the community. So, soon after a77 I can merge my 
fixes of those 15 CureCode tickets I wrote about modules yesterday, 
as well as other mezzanine fixes.

Every single broad decisision in R3 has been an enabling one for 
REBOL at large (both platform and language).   


Unfortunately, some things still require the core to be improved 
a bit, but we are nearing a point where REBOL will be able to fly 
on its own wings.   Just look at my attempt to get OpenGL to work 
with R3... it took me  10 hours of work from downloading the extension-enabled 
R3 version, downloading MS compiler, scrubbing the net for OpenGL 
reference material, libs, examples... and integrating all of this. 
 I've never coded OpenGL directly before... 


now imagine 100 of us doing this... that is what I see in REBOL's 
future within 2 years.  You will have things like trolltech QT bindings 
appearing, REBOL libs for any precise API out there... finally REBOL 
will be able to evolve with the rest of the world, and hopefully, 
impact its philosophy on the Computer Science more obviously...

I would prefer that the next version work on the new object spec 
block and the rest of the copy semantics. The version after that 
can focus on splitting off the system context. After that, I would 
love it if the rest of the PROTECT bugs were fixed.

Well, I probably think about them way too much as about objects. 
OTOH - I might have some module, but I want to hide my internals 
... kind of DLL aproach - you only provide docs with the accessible 
API and the rest should be hidden and even maybe signed ...

extensions are the key to liberating REBOL from its platform limits. 
 just like python can focus on its core, all the rest is modular 
and is maintained by other people, not Guido.


once I get the OpenGL extension working to some basic level, RT will 
never need to support it, I am pretty sure, John, Cyphre, Henrik, 
Anton, I and others will be able to give it a life of its own, all 
that RT will have to do is provide a link to it on its own site and 
say that R3 supports OpenGL natively.


same for sqlite and pekr, and many other tools many of us use daily 
and wish we could manage with rebol instead.

REVERSE rule is really cool, but of relatively limited use compared 
to the rest. And Carl says it is *really hard*.

Only some words can be infix, depending on the semantics of the operation. 
& and | (whatever they are eventually called) can be infix. The rest 
have to be prefix.

The rest of the world is catching up with where PARSE has been for 
10 years.,

When the host code is opened, I will celebrate with the rest of you, 
particularly since it will allow a level of customization that SDK 
encappers could only dream of. I can only hope that it would bring 
useful contributions though, particularly in platform support.

I have a few security concerns that haven't made the list yet - mostly 
requiring the rest of the PROTECT tickets to be done.

origanally there was just mod  I may have assumed the rest were alias'

Nope, Needs is for requirements. Only mixins import into the calling 
context. You are expected to manage your system as a whole, rather 
than micromanage. That was a basic strategic decision that makes 
the rest possible.

If you want the security framework expanded, push Carl to fix the 
rest of the PROTECT and UNPROTECT tickets in CureCode.

pekr, once carl can build a dynamic library on a platform, someone 
can do the rest, using the common host code.  as most alternative 
OSes support some level of unix C libraries, the adaptation of the 
host code should not be a big issue.  since the code is based on 
ANSI 90, just about every platform out there supports that.


and yes, on every platform that Carl has compiled the host in the 
last weeks, this means R3 runs and is usable on that platform.

If I want to do REST or SOAP, can I use Cheyenne?
Where do I have to intercept?

Graham did some work on REST support for Cheyenne. SOAP requires 
a XML encoder/decoder in your RSP script.

Nice idea! A REST-like interface to Cheyenne's MTA using the demo 
email form. :-)

I'm about to build a user login system, but I would like to know 
if it's a good idea to make this a public project so others can follow 
and contribute? Would it be a good idea to include it in Cheyenne? 
I don't intend to use MySQL for it as the rest of my site isn't DB 
driven.


I've not done anything yet, so I also need to know, what Cheyenne 
can already do in this area, to avoid duplicating functionality. 
Can I completely rely on the session context, or are there crucial 
parts missing?

It seems that I somehow get back an old session/id from someone else 
even I just opened my browser and loaded a page.


This problem shows in my REST shopping cart in that I get a shopping 
cart from someone else.

Cool, thanks Doc. I didn't report it because I'm on an older version. 
It works OK for the rest, so no rush to upgrade yet

I expect that the rest of the speedup came from the fact that Ruby 
is much slower than optimized JS. Still, not having to use Ruby is 
its own reward :)

My RSP scripts do a lot of SOAP and REST calls which use my mods

I made a start on a mod-rest but can't access it at present .. looks 
like the server has changed ip address behind nat

i have a couple of ideas how to hack this, but what would be the 
correct" way?"


You could try using the ALIAS config option. Add this to the httpd.cfg 
file in a domain section (not sure if it would work in a webapp context):

    alias "/rest" %rest.rsp

and call your REST resources with:
    /rest/asd 
    /rest/qwe


In %rest.rsp, you can put your URL parsing code to produce a "REST 
routing" and return the JSON object. It might also work with "/" 
(untested).

There are no other functions than those 3 that were added in the 
last 3 versions that call DO explicitly. The rest of the functions 
that call DO explicitly were in 2.7.5, so R2/Forward additions don't 
apply.

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.

anyhow... for now SOAP is a larger beast to tackle and I'm more concerned 
with REST stuff right now, but since the system will be working and 
you can easily extend it, there is nothing stopping you from building 
the SOAP interface.

http://www.berenddeboer.net/rest/authentication.html

this is a nice walkthru of the http auth theory with examples on 
how to do cross browser logout, forgotten password page, auto logout, 
etc etc

I thought it would have been easy, but it took a bit of doing, since 
the boot process must  *init*  the httpd.r, then setup the config 
and then init the rest.


I could have made it ugly by calling things manually or restarting 
workers, etc... but I ended up adding 2 new options to the uniserve/boot 
spec.


init and no-init which allow us to select what is initialized, without 
knowing the full list of services.

A webapp execution context is isolated as much as possible from the 
rest of the vhost.

btw, let me micro-interview you here: why the hell are u still using 
windows!? especially for development? :)


I consider that GUI are an improvement over CLI that make my life 
easier and computers simpler and more fun to use. I stick with Windows 
as my main platform because I never got used to Mac OS UI (tried 
for a few weeks, but gave up rapidly) and I found the other UNIX 
GUI less "efficient" than Windows. Also I found Windows to be quite 
transparent for my work, it just doesn't get in my way as other OSes 
tend to do, so I can focus on my work and forgot about the rest (especially 
since Vista days, I am now a very happy Seven user).


I must also add that I was an Amiga and BeOS user for more than a 
decade and spent all my college days on AIX, X-Windows and SunOS.

I will have a lot more experiences about this in few months because 
I am just working on this stuff regarding the API and export. I used 
aditional get param so user can select what format she wants. But 
I was educated by this guy that I should look at Accept headers, 
which I ignored happily ..:) .. same about statuses which I didn't 
use. Now I am getting home at this, so we can talk in a while and 
determine the most systematic and clean way for this. And such that 
will make the REST purists happy

SSL could be built-in, but if we can't get it tiny it would be a 
problem. We should pare it down to what is necessary to establish 
a secure connection and make the rest external.

I think that we should announce time for Q&A session, we can come 
up with moderation, if we wish (but not probably necessary), and 
the main person is Carl - so Carl chooses the time, the rest tries 
to adhere. As for me, I have no problem with any time, I just need 
to know - WHEN it happens :-)

when rebol came out it was hands down the best parser implementation 
out there... 10 years later the rest of the industry is catching 
up to it.  We've pushed it a little further again.

Just being able to compile the host source with a C++ compiler would 
be sufficient - having declarations still work, for instance. The 
rest could be handled with shim code, basicaly what most of the host 
code is anyways.

but each scheme will have its own  callbacks.  some schemes might 
support headers, others not... for example, in my http rss reader, 
I had a callback for the file size.  if it was too large, I'd refuse 
the rest of the read and close the port...

I can pick up the rest doing a 
read cmd

Of course what I really like about it is that there is a REST based 
API that I can use with REBOL.

I think mine allows file upload resume by sening a APPE command with 
the rest of the file

Anyway, Maarten had to do all of this because he chose to use the 
REST method of interacting with aws.  To it seems much simpler to 
use SOAP instead.

Our HTTP scheme should work with REST out-of-the-box too.

Yes, I'm sure it will work with REST ... it's just harder to maintain 
the aws interface each time they change their specifications

And if someone wants REST ... they can do it later on.

SOAP looks much easier to implement compared with the tricky stuff 
you have to do with REST.