World: r4wp

Does anyone know if there is any problem with using a ":" within 
a http URL, for the *target* part of the path.   

as such, the URL doesn't have any relation to physical disk paths.

ex:

http://mydomain.com/stuff/group:resource

I have the above working on a server, and browsers I've tested do 
not seem to have any problem with the URL, but I'm wondering more 
at large, if there are issues with it, in general.


It will be used  from within applications (java, .net, php & rebol) 
much more than from users manually using it within a browser bar.

rebol doesn't url encode the character, so it seems like its a valid 
character, but I don't want to assume, if some standard toolset doesn't 
like the color in the target.

color == colon  :-)

rfc1738 says ":" is a reserved character for possible special meaning 
in some schemes. It does not seem to have any special  meaning in 
the schemes mentioned in that URL.


But its reserved status means that it does not have to be encoded 
in any URL.

That's the theory, anyway. Practice may show otherwise.

https://tools.ietf.org/html/rfc1738

The iMatix guys use it for both zeromq stuff and wikidot.

true, good references, so I won't panick about it then  :-)

to-url is your friend

Are you sure Max?
>> x: to-url "@@@"
== @@@

all the string-based datatype convertion funcs are flawed in some 
un-expected ways.   for example, you can to-word a lot of strings 
which aren't valid words.   


this is why I asked.  Although R2 doesn't complain, it doesn't mean 
tis valid or expected.

R3 did some housecleaning in type convertion consistency, but it 
has some flaws left (and I expect we will keep finding new ones).

>> to-url "http://www.rebo.con/example1"
== http://www.rebo.con/example1

Hi, I am looking into OAuth. I see (and thank you a lot for this!) 
that Chriss Ross Gill created OAuth client part in the twitter library: 
http://reb4.me/r/twitter.html, I am reading into it, but does he 
or anyone else know how much additional work would be needed to do 
the rebol OAuth server part ?

I don't think it'd be that difficult - most of the difficulty in 
the client was making sure all the hashing was correct, the rest 
is just storage and logic.

For the most part, authorisation is based the parameters of a request 
hashed with a private key.  The trickiest part I'd imagine is the 
initial authentication - providing a safe method for the end user 
to allow the client to obtain and use the key.

End user downloads X's app/uses your

End user X downloads Y's app/uses Y's web site; X tries to access 
a function that uses your site; Y requests a temp key from you; Y 
directs X to your site with temp key, X says Y is OK, you give X 
a PIN; X goes back to Y, enters PIN; Y requests the permanent key 
from you.  Y can now do anything on your site on behalf of X.

Nothing to it : )

any tip for some session related function-set for REBOL CGI purposes? 
I am looking for the case, where Cheyenne is not an option, and need 
some simple stuff for sessions ....

acgiss.r from rebol.org an option?

Do we have anyone here that is knowledgeable / an expert in online 
markting?

I am not an expert but I have a lot of experience and also theory 
about various aspects of it because of making my apps grow (and helping 
some others)

Is Nginx obsolete now that we have Amazon CloudFront?

http://www.peterbe.com/plog/is-nginx-obsolete-amazon-cloudfront

Don't quite understand what is going on here .. have to read the 
cloud front docs

Can you trust the cloud? Not in the sense of reliability.

I trust the clouddate being watched over, and more I trust it a 100% 
being watched or even analysed.

Some things I just take as is without proof, like the earth to be 
a flat disc ;)

Yes, it's obvius. Frankly it depends on what data you want to "share". 
I like google documents for storing files to edit when I travel ,not 
very important documents. For example: if you would plan a kamikaze 
attack or write a personal diary on your sexual orientation, I didn't 
suggest you to use google documents.

It seems to me that under Red, one marvelous tool which could be 
created would be similar this new one - which I just discovered ... 
at least with my not too long vision  - based on the Cheyenne HTTP 
server, it seems it could be realized using a similar approach, to 
begin with ... http://www.wakanda.org/overview- Also available 
on Github for those interested to look at the code (may be Topaz 
friends - sinc it is base entirely on Javascript).

Could not JS everywhere someday be replaced by Red everywhere - or 
some derived fork ?

Yes; they have a good model, but it's all ugly web technologies

I agree but what else could be used - something built aroud the JVM 
- may be ? It must be a bit like Carl's REBOL based vision, isn't 
it ? Entirely self contained to be deployed anywhere but written 
once ...

Now it could be Red based instead ;-)

Yes, all true. I've long been working on a system with roughly that 
model, but we only use it internally so far

Nice, do you use some GUI for the output, kind of VId I suppose ?

Or do you send the output to some esternal receiver using messages 
 protocols ?

But then how do you catch the input if it not already part of your 
own system ?

It's a web system currently, but it's prepared to support other platforms. 
My Try REBOL site is made with it

REBOL 2 is no use to me because it would never run on Syllable, and 
REBOL 3 still only has a GUI for Windows and Amiga, so it hasn't 
been useful for me to make a VID frontend

(from #Red) - Arnold, which version of Make Doc are you using? I've 
many iterations of MD that I've hacked away at over the years, perhaps 
I'll have something that will be easier to hack?  Most recent version 
I put together for the 'Notes For the Road' site, has some nice features 
- currently hacking at it again for a more ambitious QM project...

Chris, I am stil figuring this out. I want bold/italic/(underline)/(em) 
paragrapphs separated with a blank line (easier to understand and 
no need to delete a routinely typed 'return'-key) h1/h2/h3 img (inline/left 
right center aligned) and a-href, only 1 level of bullits, and I 
think I can come along without numbered sections. I was thinking 
about mark-up delimiters on the beginning of the line like === ==+ 
==- ==* ==#   I kind of liked \note and /note or /code but everybody 
will forget if the first one will be fore or backslashed so I guess 
the indented version to produce code. Plus I want the markup to be 
from a css file. No need to make this within the script because the 
template/and a script can take care of where and which to link to. 
That's about it.

Doesn't sound too onerous - I'd say most of the changes could be 
made to the parser, then tweak the emitter to get the output you 
want. Do you have a sample document? Is this the version you're using? 
- http://reb4.me/r/xhtml

(or tried?)

This is a new version to me. I was still busy figuring out most of 
the used parses.

I tried some today, not satisfactory results yet.

figured out the line write %mijndoc.htmlÊgen-doc read %mijndoc.txt

makedoc2 results on the other hand were nicer but that was not it 
either.

The structure of MD since v2 is a separation of scanner and emitter. 
'scan-doc will break text into a block of [style content] pairs. 
'gen-doc will take that block and turn it into something, most commonly 
HTML.


The features of your doc - using your ==+, ==#, etc. are in the spec 
of the parser. Loosely explained, the parser's rule 'resets' when 
it encounters a newline.  It defines a few paragraph types that copies 
chunks of text (including 'paragraph that consumes text AND single 
newlines).  The rest of the rule determines the paragraph style and 
expected paragraph type:

  "===" text-line (emit sect1 text)

Could just as easily be:

  "==+" paragraph (emit my-bold-paragraph para)



The way a document is presented is all in the emitter. Seems this 
is where you seem to be yearning for most control. My first motivation 
using MakeDoc was stripping it of any styles - I just wanted a minimum 
of HTML markup that could be embedded and properly moulded by CSS. 
In my script above, I iterate through the [style content] list and 
use 'switch to determine how to handle each, this should be sufficient 
for documents without any complexity. It's really then just a case 
of modifying the HTML that is emitted.



Example of script used in RSP (exposes [escape-html scan-doc gen-doc]):


  <link rel="stylesheet" href="http://ross-gill.com/styles/anywhere.css">
  <% do http://reb4.me/r/xhtml%>

  <pre><code><%= mold doc: scan-doc some-input-text %></code></pre>
  <%= gen-doc doc %>

How it looks depends on the stylesheet you use.

I really should update that script though - a succinct version of 
make-doc though it is, it could use a bit of a refresh.

Chris: I'm trying to use oauth with Salesforce, can you help me about 
it?

I have consumer-key and consumer-secret, but where do I set login_url? 

I'm trying your Etsy with Salesforce. I thought that I at least should 
be able to login.

I get "** User Error: Handshake Response does not contain Login URL" 
when I try etsy/as "username"