On 30.01.2012 09:24, Stéphane Ducasse wrote:
OK, so here's my take. I try to not turn this into a wish list.
Rich libraries
While I obviously agree that rich libraries are valuable I believe it's
important to have clear guidelines to what should be part of Pharo and
what not. In one extreme I could have everything from SqS be part of
Pharo. I don't think this is the idea. You don't want to have the same
discussion for every library whether it should be part of Pharo.
FFI
First I think we need to have a problem statement. We want to be able to
use libraries written in C from Pharo. We don't implement them in Pharo
because we don't have the resources to develop them or Pharo is unsuited
for the task. This sucks because it's no longer "turtles all the way
down" but better than nothing. Since blocking C calls block the entire
VM until the call returns we need to have "threaded-FFI".
Yes, I do think that callbacks should be mentioned here. Currently the
situation as I understand it is:
- use FFI for call-outs
- use Alien for call-backs
- use NativeBoost for faster callouts? "portable plugins"?
It would be really nice to have a better, more integrated solution here.
If that results in something that's more than a one liner for a C call
that's fine with me.
64 bit
I think it's important to make a distinction between 64bit images and 64
bit VMs.
64 bit VMs
Unless you on a small device current systems are 64bit. While most of
them offer some sort of way for running 32bit applications this cannot
be the way forward since:
- it clearly marks the application as legacy
- you can only talk to 32bit libraries (see FFI)
- we don't know how long this will still be supported (Apple anybody?)
I don't know how much work is required to make Cog run on 64bit.
64bit images
While it would be nice to have multi gigabyte images (maybe not) I don't
think it's realistic to assume we have the resources to come up with a
GC that can handle such images.
SOAP
SOAP is a massive resource sink [1]. Yes it would be nice to have good
support but the cost is prohibitive and better spent on other things.
Sockets
I don't think the socket layer is holding us back. Sure, it's ugly,
sure, it can — and should — be improved, but it's not holding us back.
IMO it's missing four things:
- better documentation with examples, this is important and relatively
easy to do
- SSL, this is "just" an issue for clients since servers are fronted
anyway. I know Sven's working on this.
- sendfile support. This would allow us to send files efficiently over
the network without touching user space. Since we're fronted anyway this
is not a big deal.
- asynchronous support. This would allow us to have a large amount of
open connections for things like WebSockets. May be too much work to get
it working on Mac/Linux/Windows. This alone doesn't give us WebSockets,
we still need to write quite some infrastructure on top of it so you'll
probably want to deprioritize if not drop this.
I know I have a narrow Seaside-centric focus here.
What would be nice is to have a generic client-server framework (how
many times have I written a socket-loop?) but I don't think this should
be part of Pharo.
Load balancer
I don't think this needs to be part of Pharo. Apache already does this.
UI frameworks:
Have you considered cutting your losses? You have your existing
infrastructure that requires more resources than you have and if you
could you rewrote it. Then in addition you have new requirements and you
want to come up with new paradigms. I feel this alone can consume more
your entire resources.
Options that I would consider:
- status quo, maintenance only, no further development
- drop UI entirely, go for something like embedded WebKit
- make it somebody else's problem, once you have better FFI generate
bindings for GTK/QT/…
This is not giving up. This is not fighting battles you cannot win.
Plug Computer
Really? You have all the other places that need more resources and you
want to do even more.
Now the things that aren't on your list:
VM:
Better JIT, allocator, collector. No matter how good your VM is it's
never good enough and there's always useful stuff you can add like
monitoring.
#identityHash
It would certainly be nice to have more than 12 hash bits, especially
form a performance PoV. IIRC there was once talk of getting rid of
compact classes. I take an additional hash bit over an immutability bit
any time.
Infrastructure
If your tools and build infrastructure are holding you back fix them. I
would be quite happy if a year from now Pharo is exactly the same and
the only thing that changed is the infrastructure you use to build Pharo
is way better. I know Seaside sucks at this as well.
Migration Support
Since you're changing quite a lot of things
(SystemDictionary/SmalltakImage, file system, streams, …) it would be
nice to have support to:
- tell the user where he uses deprecated code
- assist the user in migrating to new APIs
this can also help you migrate everything in Pharo to the new APIs. You
probably want to build on top of the rewrite engine of RB. Since you
don't have static types the migration can probably only done in a
semi-automated way presenting the user a list of possible matches and
letting him select the appropriate ones. The deprecation support has
been discussed previously. This is probably the only thing in this list
that could be put into research papers.
Releases
I know Seaside sucks at this as well so this isn't a flame. To me as an
outsider the release process of Pharo is confusing. I find the release
process of Eclipse [2] [3] better. The main points are:
- One main release every year
- Two bugfix releases every year
- after the two bugfix releases a new main release is done and the old
main release becomes unsupported
The releases are date driven, not feature driven. The dates for the ga,
rc and milestone releases as well as feature and API freezes are set
years in advance. That has downsides. For example if your feature misses
a deadline, you have to wait for more than a year to see it in a
release. But it makes everything nicely planable.
[1]
http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%202007-02.pdf
[2] http://wiki.eclipse.org/Simultaneous_Release
[3] http://wiki.eclipse.org/SimRel/Overview
Cheers
Philippe
