Non-Network related schemes and URLs

I haven't proposed any new ones. I'd be happy to pare back the semantics of READ (in particular) and push them to the state of a given port.

Or could be handled in the generic for any character if it detected it in the stream. This is a spitball:

p: make port! streaming://thing
p/options/break: newline
collect [
    while [not empty? p] [
        keep read p
    ]
]

I don't have the answers for how EMPTY? works on streaming ports, but again, it doesn't seem a showstopper.

Conceptually I don't see why not, I'd put that back to you—how would you do that? This'd be a question of mapping one function to another. Alternatively, is there a natural language limit to the appropriate refinements for a given verb? Given that you can always use a block as currency for most of these verbs, what reasoning would there be not to use a dialect if you extend past limitations set by applicability on regular Rebol values? Another way to put this is why do these high-value verbs have such specific refinements?

HELP is such a big, hacky function as it is. There'd be a way.

I compiled this list a while ago. I don't treat this list as sacred in any way, it was just an enumeration from R3/Alpha (categorization mine).

One general way to approach streaming is that it be event-driven and that a limited number of events be configurable. In a way, that's kind of what Parse Machine is, but I'm only really at an early understanding of what the mechanics of that are and how tightly you could couple it to a streaming spigot.

The only such spigots we have right now (that I'm aware of) are FILE and TCP schemes. I'd love to know specifically what Earl had in mind for a CALL scheme.

What if I didn't OPEN it, but tried to use the URL directly?

change some://dbms/scheme [foo: "y" in table-y]

How would that be resolved with any behavior for what CHANGE might do for a string?

This brings up again how PORT! may claim to be an ANY-CONTEXT!. But operations like APPEND and FIND can't act like they do on OBJECT! -and- dispatch to the port scheme to do its thing. It has to be one or the other.

So how do you talk to the object of a port's implementation vs. send messages to the thing the port is representing?

Could also do MAKE PORT!

If strings generated directly from source are locked, then you'll get an error :smiley:

Isn't that slightly problematic anyway? This could come back to bite me, but how common is using a block to amend a string with insert/change/append?

I still lean toward having to explicitly transform a URL to a port (make port! or open) before acting on it as such. READ/WRITE would seem to be the exceptions to that. Being able to manipulate the URL as a series is still essential of itself.

I wouldn't propose changing that—path notation gets you the top level of the port object, verbs access the API.

>> this: make port! http://foo
== #[port! [...] [...]]

>> help this
THIS is a port! of value:
   spec            object!   [title scheme ref path host port-id local-id ...
   scheme          object!   [name title spec info actor awake]
   actor           object!   [read write open reflect close copy query]
   awake           blank!    _
   state           blank!    _
   data            blank!    _
   locals          blank!    _
   connections     blank!    _

>> this/spec 
== make object! [
    [title scheme ref path host port-id local-id method headers content timeout debug follow]
    [
        title: "HyperText Transport Protocol v1.1"
        scheme: 'http
        ref: http://foo
        path: %/
        host: "foo"
        port-id: 80
        local-id: _
        method: get
        headers: []
        content: _
        timeout: 15
        debug: _
        follow: redirect
    ]
]

On reflection, URLs can be a bit of a red herring in these cases. Yes, I can spec with minimalist syntax, say log::error or clipboard::general, but that could be a minor quibble if all you're doing is establishing those places. As with the HTTPd scheme (or most schemes), you can also initiate with a freeform block that only needs [scheme: 'thing ...] at the lead.

If these are essential services, they could live in a word by themselves and thus become accessible via regular syntax:

; in a startup script/beginning of script
log: reduce [
    'log make port! log:type=log
    'info make port! [scheme: 'log "log"]  ; spitball alternate
    'warn make port! log:type=warn
    'error make port! log:type=error
]

clipboard: make port! clipboard://

; then when you look to use them
write log/error "Some error message"
write clipboard "Text I want to paste elsewhere"

You still get the benefit of having top-level verbs and descriptive nouns. You no longer have the string conflict either:

insert clipboard image
insert log/error "Message"

For local storage, it could have more of a map!-like interface:

storage: reduce [
    'local open storage::local      ; localStorage object
    'session open storage::session  ; sessionStorage object
]

; then we can switch to using SELECT/PUT
select storage/local "thing"
put storage/session "thing" "just for now"

Does that read a little better?


memo: PUT should allow PORT! for its series argument, and be added to the actors list—although: is PUT just a synonym for POKE?

I think that this looks more like rebol syntax. :+1:

There should thus be a policy for handling HELP reflection—

help clipboard

Should likely print a descriptor of the port and permitted actors with individual descriptors

Retracted. :slight_smile: It's perhaps more commonly known as the notation for pseudo-elements in CSS.

p::first-line { }