World: r3wp

but that is an interesting thought ...  a bit out of my depth so 
far.

Just want to understand what is being done a little ...

Not for long. People don't stay newbies for long with R3 :)

Is there anything like net-utils ?

Don't know what those do yet in R2. Check mezz-ports.r in #26 - that 
is where that kind of thing would be.

I see this ...

system/intrinsic/parse-url: make object! [
	digit:       charset "0123456789"
	digits:      [1 5 digit]
	alpha-num:   charset [#"a" - #"z" #"A" - #"Z" #"0" - #"9"]
	scheme-char: insert copy alpha-num "+-."

Shouldn't some of these parse rules be defined somewhere else?

Otherwise people just keep redefining them....

This stuff should be factored out ...

Yes, there should be a module full of character sets, all read-only. 
If not read-only, then no.

(UN)PROTECT isn't done yet though - SECURE 'protect works, but what 
it is supposed to secure isn't there yet.

That's what I notice about R2 ... these character sets keep being 
redefined because they are hidden deep in the system somewhere

And refactoring is later. Right now we're focused on getting things 
to work.

Most of the internals aren't yet modlarized.

I think that a modular rewrite of prebol is needed.

The module system was designed to allow such a thing.

how does that work?  Is it like a dictionary space in forth?

which allows you to define where to look for words and in what order 
the dictionaries are searched

LOAD/header. All of the module requirements/exports are in the header. 
Even Carl's proposed export keyword will be handled like FUNCT - 
at load time, not runtime.

In the case of FUNCT uses in the mezzanine source, the code is run 
and then saved, so there is no FUNCT calls at startup time.

So, say we had a module containing all the charset definitions .. 
how would we include them to be accessible to us at run time?

You would include Needs: [charsets] in the header of the organizing 
script of your project. If we do it right, we might even be able 
to selectively import the words, though that might need some thought 
for loaded charsets - I'll give it some thought later, as mixins 
are currently file-based. I have an idea about how to do it though, 
in the preprocessor.

Ok.

And there's this in prot-http.r

crlfbin: #{0D0A} 
crlf2bin: #{0D0A0D0A} 
crlf2: to string! crlf2bin 

This stuff should be in some reusable module too

prot-http.r is itself a reusable module.

I think that the preprocessor will actually mix in the mixins itself, 
as if they were part of the original source of the calling modules. 
That way if you want to do selective import you would split your 
module into two, one that contains the shared stuff, and another 
that contains the local stuff that references the shared module. 
It's not as hard as it sounds.

maybe instead of make-scheme there could be something like make-network-scheme 
where these are automatically accessible?

How about let's worry about the refactoring later, and focus on getting 
it to work now. We can refactor on the way.

still leads to duplication of code

yeah .. always put off today what can be done tomorrow :)

Which we can deduplicate during the refactoring :)

Kaj raised the point of how much memory r2 and r3 take compared with 
the clone ...

Yes, another point for the refactoring. The clone doesn't do as much 
though.

read and write are very similar ... can we do this?

		read: func [
			port [port!]
			/write data
		] [
			either any-function? :port/awake [

    unless open? port [cause-error 'Access 'not-open port/spec/ref] 
				if port/state/state <> 'ready [http-error "Port not ready"] 
				port/state/awake: :port/awake 
				do-request port 
				port
			] [
				sync-op port either write [ data ] [[]]
			]
		] 
		write: func [
			port [port!] 
			value
		] [

   unless any [block? :value any-string? :value] [value: form :value] 

   unless block? value [value: reduce [[Content-Type: "application/x-www-form-urlencoded; 
   charset=utf-8"] value]] 
			read/write port data 
		]

should be

read/write port [parse-write-dialect port value]

well... can't use /write as the refinement .. but the idea ...

heh ..Gabriele must be top down programming .. .he writes the higher 
order code first and then the supporting definitions.

He programs in the RLP and then it topologically sorts the code.

Dunno what that means .. but it's the same in the rlp

Ah, less topological sorting than I thought.

Which is the latest ... prot-http.rlp or prot-http.r ?

later ..

ie. is prot-http.r generated from the rebol literate programming 
document?

prot-http.r is the latest. prot-http.rlp was just uploaded later.

The original prot-http.r was generated from .rlp, but has since been 
revised directly. Look at the revision history with LF and DIFF.

ok,  I see this

        spec/headers: third make make object! [
in the rlp, and in the .r

	spec/headers: body-of make make object! [

so they are different.

body-of would work, third wouldn't.

so the rlp is correct?  and the .r is not ?

reverse that ...