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. Executive summary: - HTTP(S) - SqueakDBX - VM/Cog/kernel/FFI/Alien 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. 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. 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. 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. Cheers Philippe _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
