World: r3wp

Are you sticking to the ARM5 stuff, or integrating the ARM7 extensions

Having fully access to the whole Android framework from Red is the 
goal. Running Linux binaries is the just the first experimental step.

I will stick with ARMv5 until we rewritte Red/System in Red and add 
a code optimizer. Such optimizer will be able to generate v6 and 
v7 specific code when required.

Android lets you bundle seperate binaries for ARM5 and ARM7 support 
in the same APK. Which binaries get loaded depends on which level 
the phone supports, though if there's no ARM7 binary the ARM7 phone 
can run an ARM5 binary. If you want to do the progressive use of 
ARM7 features if ARM7 is available, it's best to let the APK do it 
for you. I don't think that there are any ARM6 devices for Android, 
especially since the NDK doesn't support them, but if you want to 
add ARM6 support for other platforms then cool.

Well, I am not doing the ARM port only for Android, I target also 
iOS and some embedded boards (like e.g. the Raspberry Pi).

Never mind about what I said about ARM6. Apparently some devices 
were ARM6 but claiming to be ARM7. Progressive support for ARM6 and 
maybe even ARM7 might be a good idea to add to the ARM5 binaries.

BrianH: forget the phones of the past. Noone should care about "most 
phones running 2.2 or below". The release cycle is really fast. I 
would not care for pre 2.3 devices at all, just believe me ....

http://developer.android.com/resources/dashboard/platform-versions.html

2.1: 10.7%
2.2: 40.7%
2.3: 43.9%

Anything else is big waste of time. Just recently, there are two 
top Android phones - Samsung Galaxy SII and HTC Sensation. Both 2.3.4. 
Those are going to be upgraded to ICS. Before you finish the job, 
pre 2.3 falls into absolute irrelevancy, no matter how many tens 
of millions devices out there you claim.

Because only supporting the latest Windows version has worked so 
well for REBOL?

Not supporting phones was part of what killed rebols momentum, imo. 
Being the first alternative is hugely more valuable position than 
being a late coming alternative.

Kaj - you should know, what you are talking about ...

Whether I know what I'm talking about or not makes no difference 
in what people think of me

I think nothing bad of you :-) For me, it is easy - you can't compare 
PC world, which I would assign 3+ years of lifecycle easily, with 
mobile world. In mobile world, I would say it is 2- lifecycle, or 
even shorter. If each day 300K of Android phones is activated, then 
I would pretty much decide to start supporting the almost latest 
models, which is - 2.3. Even my girlfriend HTC Wildfire S, which 
was published on 15.2.2011, is 2.3 version. Before Doc finishes the 
product, it will be old, and unsupported phone by its vendor. Of 
course, it depends upon the featureset you are going to support - 
if supporting pre 2.3 is a no brainer, why not. But - if 2.3 contains 
some real anhancements you want to utilise,then based upon the above 
usagedata, forget at least pre 2.2 ...

Pekr, the top Android phones are the ones people already own, not 
the ones they haven't bought yet. And most of the ones they already 
own (in my country) are bought with 2-year contracts, not qualifying 
for a hardware upgrade until after that, and aren't able to be upgraded 
very much in software because that would compete with new phone purchases. 
It's good to see 2.2 adoption so high though. I am stuck on 2.2, 
btw.

Kaj, when has REBOL only supported the latest version of Windows? 
Even R3 doesn't support features in Windows newer than Win2k.

I thought Petr was exaggerating, so I responded in style :-)

I do think that in practice, REBOL has usually been a Windows-only 
technology. Especially because its biggest draw is the easy GUI, 
and this is not (R3) or not well (R2) supported on anything but Windows. 
And because it still pretends to be cross-platform, there are even 
serious deployment problems on Windows

Though to be fair, most of the deployment problems on Windows (for 
R2) come from it using the registry in a Win9x style.

We're getting a little off-topic here though. Go Red!

Yes, my response was imperfect in that REBOL doesn't support the 
latest Windows well :-/

Doc, that's some amazing progress.

Thanks James.

Sorry if this is off topic, but maybe this is relevant to Red/System:

http://queue.acm.org/detail.cfm?id=2010365

I always liked explicit lengths more than the NULL terminator, but 
Red/System has to interface with C code, so the choice has been made 
there

Interesting read though.

It's a choice we can reconsider once Red/System will be rewritten 
in Red. But we'll probably end up choosing the same option, because 
of the overheads of deviating from the format C libs and OS API expect. 
Anyway, it should be an interesting debate. :-)

Probably the best you could do would be to support both types

Sure, but the biggest issue is having to deal with a length header 
when passing to (and returning from) an external function.

Tamas sent me a link today about a nice little SSL/TLS library (http://polarssl.org). 
The bad thing is that it's GPL, but the license extends to FOSS License 
Exception: http://polarssl.org/license_exception


As I understand it, it would be possible to use it for Red but every 
future Red binary publicly distributed would have to come with also 
the PolarSSL source code and a copy of the GPL library. I think that 
burden would be too high for future Red corporate users. What do 
you think?

Isn't it possible to use similar code from PuTTY? As I see it, PuTTY 
has better licence.

License: sure MIT is better, but does PuTTY supports SSL? I thought 
it was only doing SSH.

Hm, yeah, I'm not sure. I guess, I had zlib in my mind, which PuTTY 
also do a reimplementation of. I'm not too much into SSH and SSL. 
PuTTY also have code for SFTP, if that helps in any way to make a 
SSL implementation.

Some code for hashing and encrypting could be borrowed from PuTTY. 
Anyway, those algorithms are well documented and some of them even 
have public domain implementations (like MD5).

The RFC for TLS (Transport Layer Security) is 100 pages:
http://tools.ietf.org/html/rfc5246


Is it necessary to implement TLS these days, or is its predecessor 
(SSL) enough?

Too bad, it's such a load to implement some security. :/

Would it make more sense to implement such protocols in REBOL, which 
may be easily portable to Red? (Instead of doing a C implementation.)

I think it would be doable to implement SSL/SSH in REBOL, but it's 
a big task (at least for SSL).

What would be cool would be to implement all the low-level encryption 
routines in Red/System.

Have you looked at the way, REBOL do it? The REBOL/SDK at least have 
some of that security.

REBOL provides all the low-level encryption routines required, but 
they are coded in C.  REBOL SSL implementation is also done in C 
(by Holger IIRC).

ok

The REBOL SSL port might also be using some REBOL code for higher 
level protocol support, but it's not accessible, so we can't check 
that.

IIRC, Cyphre once said, that idea for R3 was to add some port or 
other low level encryption functionality, and that https etc would 
be done in REBOL level, using thow low-level facilities ...

Geomol, the recent exploits of SSL don't affect TLS (at least 1.1 
iirc). So yes, we need to implement TLS, but maybe not SSL.

Has the PuTTY code been updated to patch the latest exploits?

Some serious bugs seem to have been fixed in the latest release: 
http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html

Including PolarSSL in Red would not only require every Red program 
to provide the library source code, it would require every Red program 
to be open source. That's unacceptable for business purposes

As far as I know, OpenSSL is the only TLS implementation under BSD, 
but it's the old BSD licence with advertising clause. This makes 
it incompatible with GPL software such as libraries one may want 
to use with Red, if they don't have an explicit exception for OpenSSL

Much GPL software that is relevant has that exception, so it's a 
limited problem