World: r3wp

you have to worry about encodings when you do conversions. i don't 
see where the R2 server is doing any of that. Also, with UTF-8 there 
is no need to worry about encodings on searches and things like that. 
The only issue could be sorting, but that is also region specific 
so it's a completely different issue that R3 cannot solve globally 
either.

As you say, if all the input is UTF-8 everything will be fine. I 
mistakenly thought that the inputs from different environments would 
have been differenlty encoded as they are with R2.

That would have to be the case with R2 clients, as the client is 
the part that handles character encoding. However, there are no R2 
clients yet. The messages appear to be UTF-8 encoded end-to-end, 
stored in binary on the server, which is encoding agnostic. Once 
we have R2 clients, they will have to handle the codepage-to-UTF-8 
encoding, or just stick to ASCII.

And yes, it does say something about the design of RebDev, that character 
encoding issues of R2 won't affect it, by design.

This is one of those things where a picture is worth a thousand words. 
 We need a diagram of the hardware and software set up, and show 
WHERE encoding becomes a problem.

For example, if you paste some text from a Word doc into a webbrowser, 
 this then gets moved to the server.  Then it gets rendered out again...you 
wil run into problems with encoding.

Word use some SPECIAL encodoing for things like " : - and '

That sounds like an issue between Word and the browser edit field, 
or between Word and the clipboard

RebDev now has a webfeed suitable for iPhone.

Reichart, I still think that is not the fault of Word (except for 
changing your character on you) or the browser.

Some shots of rebdev on iPhone:

http://rebol.hmkdesign.dk/files/r3/gui/176.png
http://rebol.hmkdesign.dk/files/r3/gui/177.png

:-)

wahouuuuuuu !!!!

I think this will be open, so someone can get to prettify it later. 
The mobile version is simpler to do so it's done first.

That's great!

Henrik, Is that in iphone's browser?

yes

10 seconds to reply...your getting slow

:-) it runs in the iPhone simulator, but it works the same as on 
a real iPhone. If you have XCode and OSX Leopard you can test it 
out yourself.

So its html...why is mobile easier?

because it's just a simple HTML page. you can't post yet and you 
can't login to your own account yet like the console version. it's 
meant to be used with lesser browsers for smaller phones than iPhone 
as well.

and it was convenient for Carl since he owns an iPhone.

Gab, not an issue of "fault", I'm simply modeling examples of problems 
I see on dozens of websites, due to encoding "issues".  Don't care 
where the fault is, just that we need better black box tools fro 
dealing with it.

Reichart: From my point if view, the root of the problem is not so 
much that Word replaces key certain key sequences with other characters 
but on eof character encoding. The text will look okay on your machine 
but unless it is correctly converted may display incorrectly on other 
machines.


As I understand, Rebol/View uses the users default "codepage" on 
Windows and  MacRoman encoding on Mac. AltME doesn't take into account 
the different the different text encodings so when I type £ (a British 
pound sign) you will probably see some thing different.
 .

eof => the

Pound is similar over many code pages: more diverse -- ½ -- Mac: 
omega; Win/west: 1/2; Win/east: right-smart quote.

On rebol.org, you get a ? -- http://www.rebol.org/aga-display-posts.r?post=r3wp453x8946

On rebol.net, we shall see -- http://www.rebol.net/altweb/rebol3/chat453.html

REBOL.org shows a ? because if blindly emits all Alte pages as charset=utf-8.

If (this works in Firefox....You change your default for the page 
-- view/character encoding / western iso-8859-1) then:
-- Peter's post shows a GBP [for his char 163]
-- Chris' post shows a 1/2 [for his char 189]

_Part_ of the problem is that altme server --> client channel (ie 
what is sent to each of us when someone posts a message) does not 
seem to contain charset information......I may be wrong about that, 
but I do not see it anywhere.

I have not idea if client-->server channel does send that information.

I don't imagine it would -- I'm not sure there's a way within Rebol 
to detect the charset in use...

Peter....I'm confused....

Word, nor REBOL have anything to do with the problem....


Encoding problems happen on hundreds of websites (big, popular website), 
that do not use REBOL, and where Word is not the source.


I'll state again... we need strong clear black box logic that unifies 
all character maps (yeah, all).

WE need a single unified character system.

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 ...