On 07/09/2021 23:17, Dave wrote:
All the symbolic links are playing havoc on windows.Well, that's annoying. Then I'm unsure how to handle Tcl modules in a
VCS. Each version of a TM will have a different file name. If that means
you also have to add a new copy of the file to the repository for each version, then there's not much version control going on. What's the
suggested way to handle this?
All the symbolic links are playing havoc on windows.
www is a package for performing http requests. It is intended to be
used in situations where the http package is too cumbersome to use
(which is pretty much always) and tclcurl is overkill.
[...]
For more information on www, please visit the chiselapp repo at https://chiselapp.com/user/schelte/repository/www
Enjoy,
Schelte.
On 07/09/2021 23:17, Dave wrote:
All the symbolic links are playing havoc on windows.Well, that's annoying. Then I'm unsure how to handle Tcl modules in a
VCS. Each version of a TM will have a different file name. If that means
you also have to add a new copy of the file to the repository for each version, then there's not much version control going on. What's the
suggested way to handle this?
www is a package for performing http requests. It is intended to be used
in situations where the http package is too cumbersome to use (which is pretty much always) and tclcurl is overkill.
The basic way to obtain a web resource using the www package is as follows:
if {[catch {www get http://www.tcl.tk/} data info]} {
puts stderr "Failed to get the web page"
} else {
puts $data
}
The package takes care of redirects, retries, cookies, and proxies and
only uses the standard way of throwing errors. The command returns the document body. Metadata is available through return options.
The package also provides extensions to handle WebSockets and HTTP/2.
For HTTP/2 over TLS a patch is needed for TclTLS. I have filed a ticket
with the patch to the TclTLS tracker (https://core.tcl-lang.org/tcltls/tktview?name=e1f9a21c67). Hopefully it
will be picked up soon.
For more information on www, please visit the chiselapp repo at https://chiselapp.com/user/schelte/repository/www
Enjoy,
Schelte.
Am 07.09.2021 um 21:22 schrieb Schelte:
www is a package for performing http requests. It is intended to be
used in situations where the http package is too cumbersome to use
(which is pretty much always) and tclcurl is overkill.
The basic way to obtain a web resource using the www package is as
follows:
if {[catch {www get http://www.tcl.tk/} data info]} {
puts stderr "Failed to get the web page"
} else {
puts $data
}
The package takes care of redirects, retries, cookies, and proxies and
only uses the standard way of throwing errors. The command returns the
document body. Metadata is available through return options.
The package also provides extensions to handle WebSockets and HTTP/2.
For HTTP/2 over TLS a patch is needed for TclTLS. I have filed a
ticket with the patch to the TclTLS tracker
(https://core.tcl-lang.org/tcltls/tktview?name=e1f9a21c67). Hopefully
it will be picked up soon.
For more information on www, please visit the chiselapp repo at
https://chiselapp.com/user/schelte/repository/www
Enjoy,
Schelte.
Hi Schelte,
I appreciate, thank you !
Great that you even care about DNS block by delegating it to a different thread.
It was always an aim by Reinhard and myself make this non-blocking in
the core... So much to do.... Do you support iocp by Ashok ?
Thanks again,
Harald
Do you support iocp by Ashok ?I would also appreciate, if Ashoks TWAPI would be usable for the TLS part.
On 07/10/2021 15:44, Harald Oehlmann wrote:
Do you support iocp by Ashok ?I would also appreciate, if Ashoks TWAPI would be usable for the TLS
part.
Both of the packages you inquire about are Windows only. I don't use
Windows myself, so I can't say for sure if they will work in combination
with the www package.
The www package provides a way to register a command for implementing a scheme. That command is expected to apply a channel transformation on
top of a socket after it has been opened. Reading the documentation, it
seems that the iocp_inet package replaces the standard Tcl socket
command. That seems like it could work quite seamlessly. The first
problem is loading the package in the helper thread. There currently is
no support for doing something like that. I also wonder if transferring
an iocp channel between threads has ever been tested.
The TWAPI documentation makes me believe that the twapi_crypto starttls command should be usable for doing https with TWAPI. That should only
require a short proc that is installed using `www register`.
By the way, I don't understand the usage as backround command.
It means, that a:
catch {www get ...}
will call vwait and events are executed, right ?
On 07/10/2021 18:52, Harald Oehlmann wrote:
By the way, I don't understand the usage as backround command.That is correct. But that is really just a safety net for when the
It means, that a:
catch {www get ...}
will call vwait and events are executed, right ?
command is invoked from direct code. The suggested way is to perform www calls in a coroutine.
Schelte.
The www package provides a way to register a command for implementing a scheme. That command is expected to apply a channel transformation on
top of a socket after it has been opened. Reading the documentation, it
seems that the iocp_inet package replaces the standard Tcl socket
command. That seems like it could work quite seamlessly. The first
problem is loading the package in the helper thread. There currently is
no support for doing something like that. I also wonder if transferring
an iocp channel between threads has ever been tested.
The TWAPI documentation makes me believe that the twapi_crypto starttls command should be usable for doing https with TWAPI. That should only
require a short proc that is installed using `www register`.
Schelte.
I'll try if I get some time on the weekend.
BTW, are you the same Schelte as sbron on the wiki?
Schelte <nospam@wanadoo.nl> writes:
www is a package for performing http requests. It is intended to be
used in situations where the http package is too cumbersome to use
(which is pretty much always) and tclcurl is overkill.
I wholeheartedly agree with "the http package is cumbersome to use".
On 08/10/2021 09:44, Ashok wrote:
I'll try if I get some time on the weekend.Thanks. It will be interesting to learn what you find.
BTW, are you the same Schelte as sbron on the wiki?
Yes, that's me.
I understand the comment about the built-in http package being awkward / cumbersome for many use cases, mostly historical hold overs, but I have
to point out a commonly overlooked strength - its test suite in its
current incarnation is orders of magnitude more comprehensive than any
of the competing http clients.
Well, did not get very far I'm afraid (using iocp in lieu of Tcl sockets
as well as TLS). Aside from the file link issues on Windows, I was not
able to get the register command to work at all. I think it is not being passed to the helper thread but did not have time to look closely.
I was asking because coincidentally I ran into your version of
getopt-like packages on the Wiki while looking for that class of functionality. Very nicely done, full featured, expected behaviors
supported and a very intuitive switch-like Tcl-ish interface. My pick
for Editor's choice :-)
As far as I could quickly tell, there are about twice as many tests for
the http package as there are for the www package. Not exactly "orders
of magnitude". But please let me know if there is anything you feel is missing from the test suite of the www package.
Despite the more extensive test suite of the http package, it still has
a number of bugs/issues. Which is one of the reasons I chose to write
the www package from scratch, rather than build it on top of the http package.
So for now, probably the only way to test the package with iocp would be
to modify the source code to load the package in the helper thread.
On 19/10/2021 00:13, Schelte wrote:
I have added a new configuration option to the www package. You should
now (hopefully) be able to use the iocp socket command by doing
something like this at the start of your script:
package require www
www configure -socketcmd [list apply [list {path args} {
set ::auto_path $path
package require iocp_inet
tailcall socket {*}$args
}] $auto_path]
Clearly, you can simplify this a bit if the iocp_inet package is in the default auto_path.
Probably needles to say: The socket command replacement is executed in a separate thread, so it has to be self-contained. You can't use any procs defined in the main thread.
Schelte
I have added a new configuration option to the www package. You should
now (hopefully) be able to use the iocp socket command by doing
something like this at the start of your script:
package require www
www configure -socketcmd [list apply [list {path args} {
set ::auto_path $path
package require iocp_inet
tailcall socket {*}$args
}] $auto_path]
Finally got around to this and it works as advertised.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 61:53:55 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,620 |