World: r3wp

This group is to discuss priorities for the REBOL 3 project. Civil 
debate welcome :)

Here's a good start: http://rebol.com/r3/docs/project.html

my priorities
1. Device extensions
2. Image datatype support in extensions
3 Vector datatype support in extensions

My priorities:
1. Finish PROTECT and the other security stuff.
2. Device extensions.
3. Port/networking stuff.

4. Modularization of the built-in code (might be more of a personal 
project)

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

I might be a bit more detailed, and I will not mention things other 
ppl mentioned here:


The stuff that needs adressing, at least in the form that RT states, 
WHEN and possibly in what form, are those things implemented

1. Concurrency (tasking)

2. RIF - what happened to this concept, and how important it is for 
3.0 beta?

3. Codecs - is this concept of read-all-data-into-memory usefull 
at all?

4. Unicode - what about more locale support? I need to be able to 
sort using collations, or Unicode is half-way implemented for me

5. find/not - some ppl talked about it as about important feature. 
I can see only find/first on the list

4. capacity to copy directly within image! buffer from the extension.

5. tupple support in extensions (very usefull for graphics related 
functions)

Henrik, I think carl thinks you can start work on your point (1) 
right away if you want.

Well, while Carl mentions that the table is hard-core :-) only stuff 
(so no even mezzanine networking protocols for e.g.), it also contains 
sound addressed. In that regard I wonder, if we should extend it 
by Henrik's requests (which would be very welcomed on my side, unless 
we call it REBOL 3.0 Core Beta release)

pekr, my devices proposal actually extends a helping hand into thread 
space, LNS and inter-rebol coms  :-)

Maxim, the reimplementation of VID3.4 needs to be done by Carl. He 
has some specific specs he wants to use.

pekr, for now it does seem Carl is talking about core only.

Anyhow, I agree with other priorities. Mine are far down the list.

strangely he puts the GUI as part of "community projects".

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