World: r3wp

If I was a betting man, by 2020 UTF-8 will reign and compsci grads 
will need a history book to learn about ASCII.

Reichart ...you are right thep problem is one of encoding. My point 
is that because Rebol/View uses different encoding systems on different 
platforms it  is left to the application to either ignore the encoding 
differences or handle them.


This may be quite difficult if, as Chris indicated, it is not possible 
to determine which Windows Codepage is in use from Rebol/View. 


Tthere is a single unified character system (Unicode ) but there 
are at least five different ways of representing it (UTF-8, UTF-16LE, 
UTF-16BE, UTF-32LE & UTF-32BE). Standardisation is a long way off.

Never copy what you can do better your self.

English got in the way, I think that should read: "Never copy what 
you can improve easily"/

Reichart, what I mean is that you don't even need tools, as long 
as the server software properly emits only utf-8 and reports that 
it accepts only utf-8... after doing that, if there are still browsers 
that do not comply, then we can start talking about tools (which 
are trivial, most of the time, by the way).

Another part of the problem, at least from the webpage viewpoint, 
is that each of us could be posting AltME messages in different charsets.


All the HTML emitters for AltME worlds that I know of (AltME's own, 
REBOL.org, REBOL.net) emit a single webpage file, so it can only 
have one charset.


To do it right, each post should be emitted as a separate document/frame 
item. Then they'll each have their own charset.....That's a lot of 
extra work. Let's hope Gabriele's solution (a utf-8 universe) happens 
before that becomes essential.

Gab, yes...I think we are in agreement.  However, this is not just 
about websites for me.  


I guess, what I want for us to reach a level where THIS is not something 
programmers even talk about.  The core routines take care of themselves.

Brian -- ASCII is a subset of UTF-8...

With QM, I try to assume (and enforce) UTF-8 (declaring on forms, 
html escaping everything ASCII+), but it's definitely a chore.

Exactly, it is the chore part that concerns me.

Yes. It's 2009 and we (as in industry) don't even get the computers 
to do *this* for us.

THAT is my POINT!

It's like when traveling you know you can have dinner. It's just 
that you have to learn to explain that the food you're being served 
is not poisoned for every language, country.

You just want food!!!!

Some small news - new R3 alpha released, fixing form/mold problems. 
Carl says, we are very close to start usage of RebDev, hence very 
close to let more developers to touch the next R3 alpha, along with 
GUI. What will follow is further work on GUI .....

... and me panicking :-)

Another thing - today I asked Carl about differences between RebDev 
messaging system, rmp:// (IOS protocol) and LNS (RebServices). As 
you probably know, LNS is not fully finished, although functional. 
Carl might introduce some small shift to its architecture, to make 
its usega a bit easier.


Some few weeks ago, I chatted with Carl about messaging. While he 
likes syndication of communication channels for RebDev, I think there 
are systems out there, which provide real multi-protocol, multi-system 
syndication. E.g. Python's Medusa, or our Uniserve. As for me, I 
will always prefer dynamic, exensible, run-time pluggable system.


The most important opinion of mine on that is - let's accept any 
such system as a standard for R3 (that does not mean, there can't 
be any other system done by developers).


So, because RebDev messaging is third such system from RT (rmp://, 
LNS the former ones), I asked Carl to make some higher level decision, 
if possible. Carl agreed, and said that it would need more developer's 
input, probably a virtual conference.


... we have networking gurus like Maarten, Gabriele, Robert, DocKimbel, 
who worked on some such frameworks in the past. I would like to know 
interest of ppl in such a topic.

Petr, I agree on having one such system as the R3 standard and not 
to fragment right from the start. I think RS is quite good and done 
for 80%? So, using this, finishing it and than polishing it should 
get a pretty good base for everyone.

Refactoring the RS code in a way that I can plug in a different transport 
layer (via external DLL functions) would be very nice. With this 
we could use SSH channels etc. This would allow us to add things 
like auto-tunneling through proxies.

Robert - the "problem" with Carl is, that he easily finds more advanced 
systems too complex.

Robert - discussion of you, networking gurus is needed. I don't know, 
where is the distinction of transport and service layer in LNS. If 
LNS is mostly services layer, which can be used over whatever transport, 
well then. But if not, why not to go with some multiplexing engine 
like Uniserve, which, via plug-ins, dynamically can "syndicate" (interconnect) 
us with the rest of the world - IRC, Jabber, ICQ, http, SOAP, webservices, 
whatever ...

RebDev messaging works at a higher layer than LNS or rmp:// - human 
messages, not program messages. Not comparable.

Uniserve works at a lower layer. You can implement LNS on top of 
Uniserve, and RebDev on top of LNS.

hmm, but LNS is also a transport in itself. It at least can work 
upon http and cgi ...

All of these are transport layers, even Uniserve (which works on 
TCP). As long as things are simple at a given layer we're fine.

Pekr, you're welcome to use the fms applications at rockfactory.us 
for any virtual conferences you want to set up, if that'll help at 
all ... that is, until we get a full REBOL video conference solution 
:)

Just lemme know if the gurus ever want to do anything like that...

My response to a query aboit REBOL3 on REBOLtalk would not make a 
marketing person happy:
-- year old alpha
-- no obvious contact details for those wanting to get involved.
Could someone better connected do a better job, please?

http://www.reboltalk.com/forum/index.php/topic,1827.msg4644.html#msg4644

I'm on it.

does R3 have library! capabilites so far?

Some status (not much since Pekr told most of this):


- Improved console presentation (sounds so Windows-like, doesn't 
it? :-)) in the latest R3 alpha. http://rebol.hmkdesign.dk/files/r3/gui/178.png

- Carl wants to do a larger release of R3 "soon". This involves a 
merge of my skin or parts of it. I'm not sure everything you see 
in screenshots can go in, because those parts are not clean enough.
- Still working on RebDev.

- Carl noted that RebDev helped him find many bugs in R3. Some of 
those are fixed.

- GUI has not progressed for a couple of weeks as I'm working on 
a big R2 project. I will get a few days in January to help, but I 
won't get more time until mid-March at best.
- Some Devbase submitted changes and fixes are added to R3.

The intended priority for RebDev front-ends is:

1. R3 Shell (doing this now)
2. HTML mobile (doing this now)
3. R3 GUI
4. HTML pretty
5. R2 Shell
6. RSS feed
7. Whatever people want to do.

Maxim, untested, I think.

No load/library in the current (ie jan-2008) public alpha.
Not sure if it is in later versions.

I don't see it here.

and are there any specs on how to use the rebol.dll itself outside 
of the environment RT is building?

Sunanda - all Carl's energy is spent on prepraration for the next 
alpha release, the public one. I think it is wise to have infrastructure 
ready first, to handle the load it might cause.

So - work on GUI is postponed right now to above mentioned activities. 
Once it is done, there will be release to more wider audience, before 
any work on GUI continues.

wrt library... ok

Petr -- But there needs to be some evidence that the project is still 
alive and deliverying.
A one-year old public alpha is not that.

Maxim - have you read my proposition to start wiki page to define 
our needs for library component? We should really do so!

You will surely agree, that so far, supporting C code is mostly a 
joke ...

rebol3 /core really should be finished before any rebol/view is released. 
 just like the very first v1 release.

yes... I am doing so right now... implementing the windows bitmap 
handling and gdi is *NOT* fun.

Maxim -- load has to some extent been replaced by transcode.
So lack of /library may mean the functionality is elsewhere.
The same is true with load/header.

(in R2)

I always tought that the load/save refinements for library and image 
formats was pretty strange.

pekr... R3 MUST support unsigned values for starters.

even if only in structs

re R3 /library. I talked about it with Carl one year ago. He was 
not sure /library component will be added as-is. Instead, he thought 
about making it a plug-in. But - plug-ins are done from some 80%? 
They also need 'modules, whicha re not finised too. But - we could 
do some preparation work.

furthermore, the ability to contain or point to structs must be explicit... 
right now, I can't deduct from the library docs if structs pointing 
to structs is even possible!