thanks Philippe. I worked more on the document but I will integrate your ideas in it and will send it again.
Stef On Feb 5, 2012, at 6:43 PM, Philippe Marschall 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 > [2] http://wiki.eclipse.org/Simultaneous_Release > [3] http://wiki.eclipse.org/SimRel/Overview > > Cheers > Philippe > >
