World: r3wp

I'll just do a search and replace on my scripts directory

The real trick is that R3 network protocols should be put in modules, 
not scripts. Otherwise there won't be much code sharing.

Scripts are for end-developer apps, not infrastructure.

Again we await the exemplars from Carl ...

This is all mezzanine stuff. We don't need to wait for Carl.

We only need Carl's help with native stuff. We could use his help 
with certain other activities that he's good at, but we don't *need* 
it.

Ok, I'm confused .. i see Gabriele's prot-http says it is a module, 
but there is no exports

It doesn't export anything - it doesn't need to.

the reason being ?

Once the protocol is installed then you just use OPEN, READ and WRITE, 
etc. directly. You only need exported helper functions for some protocols, 
but http is covered by the default actions.

For instance pop or imap might need a SEND-EMAIL function exported, 
and maybe a SET-NET. That's all.

I'd be wary of using a SEND function until we really know what the 
services infrastructure is going to look like.

So, any function which takes a port as an argument inside the module 
( if it is also a scheme ) does not need exporting.

The rest we have to access via the module path

Nope, not even then. Most protocol functions don't have to be accessed 
from the outside except by the port infrastructure. Functions in 
the scheme are only called by port infrastructure, and most functions 
are helper functions. The only words you export would be user-visible 
functions that users are supposed to call directly.

That presupposes that there is no reusable code in the modules

In general you never access a word through a module path. If it needs 
to be user-accessible, export it or wrap it in a function that you 
export. System accessible is another matter, and usually involves 
installing something somewhere in the system hierarchy (like system/schemes, 
for instance).

No, it supposes that you are refactoring your modules so that the 
reusable code is getting exported from a reusable code module, then 
imported into your specific module.

The module author can not possibly know what users might want to 
reuse

Then provide the source. Making things safely reusable takes planning. 
Providing the source doesn't (or at least not as much).

Say I wanted to create a http header, I would naturally want to use 
Gab's make-http-request function that is not exported

Say you wanted to create an HTTP header, and it had nothing to do 
with HTTP. Are you sure you want to create the same header? Or are 
you sure that you don't actually want to extend the existing http 
scheme? The author isn't psychic.

Making code reusable takes planning. If you want to reuse code safely, 
do the planning. Or copy and paste.

And we arrive at a situation where you end up duplicating code everywhere

Not really. You could do the planning, and refactor. Even Gabriele's 
code, since he provided the source.

But we lack the sources to recompile the core with our refactored 
code

We can replace a protocol in memory if need be. Or load one from 
host code. Or better yet, fix the source in DevBase.

Right now I would rather see duplication, so we can get a better 
idea of what needs to be reused.

Well, I don't want to see all the code duplication we have in r2

every script defining digits as a bitset even though it's already 
defined in one of the schemes

We're in the planning phase when it comes to scheme infrastructure 
(not port infrastructure). I want to tweak/redo the scheme dialect, 
but there haven't been enough examples of schemes yet to see what 
needs to be done. Perhaps making a protected collection of standard 
bitsets would be a good idea, but who can say for sure at this point?

You'll help out a lot there, apparently :)

For that matter, the exports of the http scheme weren't planned by 
Gabriele at all. There was no module system when he wrote it, and 
system exports didn't work yet when Carl put it in a module, so there 
were no code exports. And for that matter, reuse was unnecessary 
because there was only one scheme. Assume that the code needs refactoring.

I'd like to ask how we might manage the download of a large file 
by thehttp protocol

Actually I just tried downloading a 16Mb file and it timedout in 
R3 but downloaded okay in R2.

So, it seems you need to open the port instead, and then modify the 
timeout

Maybe what should happen instead is that if you receive other than 
xml, text, then the data should be streamed a file and a file! returned 
instead ( like Cheyenne does with html uploads ) ...

BrianH: I think that there is now bunch of examples of schemes, so 
it might start to become apparent, what is needed :-)

After the first of the month, that's the plan.

There are a few schemes now but they're basicall all written by me 
... so I don't think there's much variety there.  Others have commented 
that the awake handler should be as small as possible and to keep 
the state machine outside ...

If anyone is interested .. this is the "bug" I came across

http://developer.amazonwebservices.com/connect/thread.jspa?threadID=41782&tstart=0


I had to change my to-iso8601 function to add the extra precision 
required.

aha, cool, those links I was looking for!

(ports, schemes, etc)... I did get my product mostely working in 
R3 (large % networking) up to about 90% and to be honest, I didn't 
put much time into the porting R2 -> R3 yet.

Where's the video codec you did??

I need to port it to the latest R3.  There was a point where the 
GC got changed and the real-time performance went crazy, and I want 
to blend it into the new architecture...so I don't want to put out 
something that requires an old R3 alpha...and the dialect is not 
100% clean...guess I'm being kind of a Carl here...not ready for 
prime-time yet.

This is the best place we have now to discuss SSL on R3.

Fine with me

How would I implement a ssl:// port scheme in the hostkit, that behaves 
just as tcp:// does, but allowing me to hook the native actors (open, 
mainly)

The tcp:// scheme is defined in the host kit, as are all native schemes.

no, only the tcp device is defined in the hostkit