World: r3wp

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

S: Do you ever sleep?

So... I wonder what time works best for chat?  If say, developer 
is 4PM in France, then that would be 8AM Pacific time? (Depending 
on DST.)

4PM is not good in France, for those who work

Ok... what time do you think is best?

i would say 8PM-11PM

Ok, good. That's better for me too.

I think that we should announce time for Q&A session, we can come 
up with moderation, if we wish (but not probably necessary), and 
the main person is Carl - so Carl chooses the time, the rest tries 
to adhere. As for me, I have no problem with any time, I just need 
to know - WHEN it happens :-)

1) portable fot system working with VID/draw

2) better way to handle events directly in draw content ? (don't 
know if this would be a gain or not)

portable fonts system working with VID/draw this means a font system 
than render the font for the same font file the same way on linux, 
macosX, windows seven, vista xp etc...,  and being able to know precisely 
the size in pixel on screen of the characters from the font we are 
using any time and any momment ( this is related to area-tc and what 
we noticed developping it actually area-tc rendering engine / event 
system works only properly on windows XP due to limitations in  rebol 
2) 

3) better draw dilect more hum light  and flexible ( no need to give 
the coords and call the text instruction in draw bloack any time 
we want to change the color or the font style of a particular bunch 
of text drawn on screen)

instead of [ pen 0.0.0 text antialised  0X0 "one text" pen 255.0.0 
text  0x20 anti-aliased " red " etc... ]  it would then nice to have 
" text antiliased black "one text " red " red " etc...]  the matrix 
push and clear should be a way too  optimise the management of segments 
of  set of draw instructions ine the  draw block.

dig up one of the proposition made a year ago by carl regarding the 
way draw could   work using aliases ...  hum at that time we hadn't 
worked on area-tc and the aliase to short set of instructions and 
arguement comming often in the draw block apeared us like a meaningless 
thing  but this kind of feature would be nice in a project  like 
area-tc where the size of the draw block matters in many way (debugging 
200K  of draw instruction to back trace why your text drawing engine 
is not drawing the proper way is a pain believe me) ....

shadwolf, graphics are not in priorities for this round of REBOL. 
 we need to finish the core first.  once that is done we will be 
able to fix some of the stuff in the host code ourself, thus allowing 
us to work in helping Carl... but there remains much lower and important 
issues than VID right now.

A few quick replies...

Three things come to mind:
1. Yes, core is the focus.... for me and for right now.
2. View graphics is open source (see next msg.)
3. VID is also open source.