On Aug 7, 2010, at 2:00 PM, Philippe Marschall wrote: > On 02.08.2010 21:50, Stéphane Ducasse wrote: >> Hi guys >> >> with the experience around the XMLRPC project, ESUG wants to change strategy >> to help growing business at the technical >> level. So what are the key areas where you think that effort should be >> supported to help you making business in smalltalk? > > Rather than imagining what problems non-users could have I'd focus on > what problems existing users have. Instead of building libraries that > you'll have to maintain forever I'd focus in infrastructure that allows > users to write the libraries they need themselves.
Yes! But a poll is interesting. > Executive summary: > - HTTP(S) > - SqueakDBX > - VM/Cog/kernel/FFI/Alien The last line is really into our radar and our engineer will make sure FFI/Alien will work 100% Noury and luc really need sockets and started to rewrite them using Alien and this something that we want to push too. > Something that always comes up is a usable HTTP client that does HTTPS, > proxies, authentication, multipart, not have to load the entire > response/request into memory, probably even keep-alive. WebClient could > be the solution here once you have documentation, examples and don't > need an override on String >> #,. As more and more things are HTTP based > these days having a good HTTP story is important. Again WebClient has an > advantage here because it answers both the client and the server part. > NTLMv2 would be awesome but may not be possible. For WebClient this is good that andreas started to clean that part we really want to support that effort and this was also in our radar > What also seems to come up frequently is relational databases. I have > already meat people who told me "I would use Squeak/Pharo over dialect X > if only I could connect to Oracle". Having a common interface for > relational databases despite all the "NoSQL" hype is important even if > it requires installing native (C) client libraries. SqueakDBX seems to > be the only option here right now. this is why ESUG supported this project over the years. > And finally having a fast and stable kernel and runtime including > Sockets/Semaphores/weak array finalization. That includes helping Eliot > to make Cog a replacement for the current VM. That includes having a > prebuilt Coq VM available with warning signs. That includes having an > easy way to bind C libraries without writing a plugin. See above. Yes > That includes > non-blocking FFI calls. That may include having a way to do > sendfile()/TransmitFile() on sockets. That may include instead of having > Semaphore, Mutex and Monitor only having the class that you're supposed > to use. That may include a ReadWriteLock. I do not know :) but we will know it soon (by january or february) > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
