Hi Stef, Similarly to Philippe my feedback is based on a Seaside/web centric view of how I use Pharo.
I'd echo Philippe's concern about looking carefully at how much effort is required to rework Morphic vs using an existing UI library or WebView. From a web centric view I'd emphasis building a remote browsing interface over significant Morphic work. At FOSDEM this weekend I was impressed with the progress Craig Latta has made on spoon recently [1] [2]. Does his work on remote browsing and micro kernels fit into a future Pharo? As I develop with Pharo and deploy with Gemstone, maintaining some level of compatibility between Smalltalks is important. I note the problem raised with XML compatibility between dialects [3]. So the ability to maintain a compatibility layer such as Grease is important, as is the ability to re-use packages between Pharo and Gemstone. [1] http://thiscontext.wordpress.com/ [2] http://netjam.org/spoon/naiad/ [3] http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg56924.html On 5 February 2012 17:43, Philippe Marschall <kus...@gmx.net> wrote: > 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<http://www.innoq.com/soa/ws-standards/poster/innoQ%20WS-Standards%20Poster%202007-02.pdf> > [2] > http://wiki.eclipse.org/**Simultaneous_Release<http://wiki.eclipse.org/Simultaneous_Release> > [3] > http://wiki.eclipse.org/**SimRel/Overview<http://wiki.eclipse.org/SimRel/Overview> > > Cheers > Philippe > > >
