World: r3wp

Let's keep this group as much chat free as possible. Initially, unless 
Carl opens the blog (if he does so), I want to point him here :-)

Should we make this group [web public]?

If only because it makes it easier to point Carl towards specific 
posts :)

I am OK with it. In fact I thought it will be web-public ...

I don't see why not.  :-)

My priorities would be related to graphics:
1. VID3.4 re-implementation according to Carl's specs
2. Cyphre's improvements to View, Draw, fonts, etc.
3. VID3.4 skin
2. Cyphre's improvements to View, Draw, fonts, etc.
1. Concurrency (tasking)

Making it web public will preclude flame wars (in theory).

These are my wishes - oups
1. VID3.4 re-implementation according to Carl's specs
2. Cyphre's improvements to View, Draw, fonts, etc.
3. VID3.4 skin
4. Concurrency (tasking)

Thanks.....I'll make it public.

This group was suggested to Carl on R3 Chat ...

What I mentioned before were my short-term priorities. My medium-term 
priorities are:
1. Business stuff, including licensing.
2. Concurrency.

https anyone?

and/or ODBC? (ODBC can't be done on all platforms probably, so how 
to aproach it?)

I guess you missed it when Maxim and I wrote "Device Extensions".

Need some more lower level encryption before HTTPS, I think. I think 
also that it belongs in the same category as SSH, SFTP, etc.

ODBC as an extension is OK, https (ssl) is not - it should be default 
part imo, as there is no web without the security and certificates.

Wrapping UnixODBC in an extension would be a good idea, though that 
likely falls in the category of a third-party or community project.

SSL could be built-in, but if we can't get it tiny it would be a 
problem. We should pare it down to what is necessary to establish 
a secure connection and make the rest external.

Opening the host code is definitely a short-term priority, before 
or during the beta period.

I have spoken to Carl about using putty's completely self enclosed 
and extremely tight, completely up to date SSL code as-is.

we need an in-progress column

Carl is working on PARSE, but it's not possible to tell from the 
table.

will carl actually update the table?

we might try the trick - look at the source, maybe the column is 
done by another column separator marker, no? :-)

1. Extensions with Callback support: This makes R3 immerdiatly ready 
for the server-side where no GUI is required.

1, Better console for Windows systems
2, host source code
3, device extension


generally speaking graphics should be made available via extensions

concurrency
RIF

GFX is part of Host layer, and Host layer is going to be internally 
done using Extensions probably, so your request might be accepted 
:-)

But when?

Dunno. Beta is scheduled for Autumn 2009. I will be glad, if complete 
Core, Host with all Beta requests implemented, will be out for the 
Christmass time ...

1. View/GOB
2. Win, Mac and Linux
3. SDK

I share my priorities with Maxim with a hope he will share his know-how 
with us so we can use it together to make REBOL better.... and of 
course releasing Host source.

1.  Mac and Linux

2.  View/GOB
3.  Better console
4.  SDK

Sqlab, a better console for Windows requires the GUI to be built-in, 
not in extensions. The GUI would be used to make the console.

However, the low-level graphics portion of the GUI would be in the 
host portion of R3, which interfaces the core in similar ways.

BrianH: I am not sure you are right about the console. I think Carl 
is considering putting R2-like console back. It is obvious from the 
priority list imo ...

R3 October plan - http://www.rebol.com/article/0432.html

What I most want in R3 console are not different colors or fonts 
etc. , but a way to write commands longer than one line, 

meaning that I can define a function over more than one line and 
easily paste into the console.

R2 seems to delay checking and doing the input after all brackets 
are closed.

I can not understand that this requires a GUI.

IT does, or it does not, it depends. For system admins, they need 
raw system console, so that they can use R3 in windowless environment, 
or via ssh, etc. That is not possible with R2 on Windows. But - it 
is not REBOL's fault, that Windows default console is absolute crap. 
So I think that Carl might be considering adding R2 console back 
as an option (the raw mode still has to stay with us, it is needed).

Windows will not make better console. If you want one, use PowerShell 
(.NET based, IIRC)

Seriously, there are already Windows console alternatives on Windows. 
Let's just find a good one and test R3 in it. It'll be quicker.

BrianH: that is not a good solution. If we want a good one, let's 
have it at least in R2 level. If you want the raw one, you HAVE to 
count on the default Windows version. Suggesting ppl to download 
xy MB crap is not the way to go to try REBOL at all ...

System admins will not surely download better console, in order to 
get better REBOL experience?

System admins won't be able to use a GUI console at all - they need 
a version of REBOL they can call from batch files.

On the other hand, the R3 console isn't that great by Windows console 
app standards - it allocates a console even when started from one. 
It really needs to use the console it was started from if any.

This is why we can't use Console2.

As Carl did not show up here, I think that we should start editing 
priority document anyway. What do you think?

.............................

As I noted, I would be back in a few hours. So... here I am.

The current top priority is to get stdio working properly.  For Windows, 
this is a pain, but for everything else, it's quite easy.

re