[Pharo-project] Poll: missing libraries to support business
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? Stef
Here are some of the things I'm missing: fulltext search/text retrieval ---------------------------------------- - fuzzy search (http://en.wikipedia.org/wiki/Approximate_string_matching) - proximity search (http://en.wikipedia.org/wiki/Proximity_search_(text)) - stemming (http://en.wikipedia.org/wiki/Stemming) - faceted search (http://en.wikipedia.org/wiki/Faceted_search) If there were a good support or integration with collections that could ease a lot of use cases especially in web environments. At the moment I'm serializing objects to XML documents and put this into SOLR (http://lucene.apache.org/solr/). Before tsearch2 on postgresql spatial data services ------------------------------ - quad-tree (http://de.wikipedia.org/wiki/Quadtree) - r-tree (http://en.wikipedia.org/wiki/R-tree) Again nice integration with collections would be very powerful. Spatial data are more and more important. There is support for google maps and such but no support to store spatial data. Back then I used postGis (on postgresql) for that. authentication frameworks -------------------------------------- - OAuth (http://oauth.net/) - open-id (http://openid.net/) To ease the authentication of users and web APIs those two mentioned are quite important (needs checking) That are the ones I miss on a regular basis. hope this helps, Norbert On 02.08.2010, at 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El lun, 02-08-2010 a las 22:26 +0200, Norbert Hartl escribió:
Here are some of the things I'm missing:
fulltext search/text retrieval ---------------------------------------- - fuzzy search (http://en.wikipedia.org/wiki/Approximate_string_matching) - proximity search (http://en.wikipedia.org/wiki/Proximity_search_(text)) - stemming (http://en.wikipedia.org/wiki/Stemming) - faceted search (http://en.wikipedia.org/wiki/Faceted_search)
If there were a good support or integration with collections that could ease a lot of use cases especially in web environments. At the moment I'm serializing objects to XML documents and put this into SOLR (http://lucene.apache.org/solr/). Before tsearch2 on postgresql
spatial data services ------------------------------ - quad-tree (http://de.wikipedia.org/wiki/Quadtree) - r-tree (http://en.wikipedia.org/wiki/R-tree)
Again nice integration with collections would be very powerful. Spatial data are more and more important. There is support for google maps and such but no support to store spatial data. Back then I used postGis (on postgresql) for that.
authentication frameworks -------------------------------------- - OAuth (http://oauth.net/)
+ 1 to oauth. Now that Cyrpto code is working ok and webclient with https support exists, should be possible to have this. this will permit integration with facebook for apps.
- open-id (http://openid.net/)
There are a simple (incomplete) implementation of this in squeaksource, I think that was an experiment from Philippe, but it could be supported to have a complete implementation for smalltalk.
To ease the authentication of users and web APIs those two mentioned are quite important (needs checking)
That are the ones I miss on a regular basis.
hope this helps,
Norbert
On 02.08.2010, at 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
=Platform integration= -multiple host windows -deeper platform look 'n feel =Documentation= cheers Mike On Mon, Aug 2, 2010 at 8:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 2 Aug 2010, Michael Roberts wrote:
=Platform integration= -multiple host windows -deeper platform look 'n feel
wxSqueak is a perfect match. Too bad it's not finished and it uses ToolBuilder.
=Documentation=
Nobody likes to write documentation. Levente
cheers Mike
On Mon, Aug 2, 2010 at 8:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente Uzonyi-2 wrote:
=Documentation=
Nobody likes to write documentation.
I've started to enjoy writing class comments and tests. Especially when I go back to system classes (that I figured out every last detail about) a week later and can pick up where I left off :) Sean -- View this message in context: http://forum.world.st/Poll-missing-libraries-to-support-business-tp2310842p2... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
I've started to enjoy writing class comments and tests. Especially when I go back to system classes (that I figured out every last detail about) a week later and can pick up where I left off :)
Hi sean (prononced chon in french ;-D ) It was nice to meet you. If you have class comments for the core please send them. Stef
Somethings I would like to have: - Lockdown/Deployment Mode/disable programmer facilities (As was discussed here) - UI builder to desktop applications (Also discussed here) - Interface with nosql databases - Parallel processing / map reduce / other strategies to scalability Let me think about other things :) 2010/8/2 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Aug 2, 2010 at 9:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>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?
I would prefer: What kind of powerful task should be made easy out of the box ? - connect to a legacy MySQL database, send SQL requests and manipulate results - describe relations (a Library has many Books and Subscribers) -> generate -> Seaside (and/or Iliad or desktop) / view / controllers / models / database automatically setup. Plug in custom relations. - build an UI and create custom widgets. - deploy desktop and/or web app. and showcases + documentation. So Pharo can attracts new developpers who can say "wooww, so easy !". More developpers -> more business needs -> more contributions. Laurent
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/3 laurent laffont <laurent.laffont@gmail.com>
On Mon, Aug 2, 2010 at 9:50 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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?
Libraries Make connecting to C libraries/Java libraries as plainless as possible. Make discovery of available Smalltalk libraries less painful: * There's little or no differentiation on squeaksource between great, well-tested reliable code, and "my first Smalltalk project" * Be great if ESUG sponsored the infrastructure for something like Apache commons (http://commons.apache.org/) for Smalltalk projects. They have three designations: 1) Commons Proper - repository of reusable components 2) Commons Sandbox - workspace for component development 3) Repository of sandbox components that are currently inactive * This would aid in the discovery of projects. * Ideally projects in the equivalent to "commons proper" would be part of a CI system like Lukas' Hudson setup (http://hudson.lukas-renggli.ch/) HTH Nick
On Aug 3, 2010, at 9:16 AM, Nick Ager wrote:
2010/8/3 laurent laffont <laurent.laffont@gmail.com> On Mon, Aug 2, 2010 at 9:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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?
Libraries
Make connecting to C libraries/Java libraries as plainless as possible. Make discovery of available Smalltalk libraries less painful: * There's little or no differentiation on squeaksource between great, well-tested reliable code, and "my first Smalltalk project"
yes we will have to address that and I believe that it should go via metacello
* Be great if ESUG sponsored the infrastructure for something like Apache commons (http://commons.apache.org/) for Smalltalk projects. They have three designations: 1) Commons Proper - repository of reusable components 2) Commons Sandbox - workspace for component development 3) Repository of sandbox components that are currently inactive
good idea. Now inactive does not mean sandboxed :) but yes we should have a categorisation of the projects. We should be able to put that in place with bibliocello.
* This would aid in the discovery of projects. * Ideally projects in the equivalent to "commons proper" would be part of a CI system like Lukas' Hudson setup (http://hudson.lukas-renggli.ch/)
HTH
Nick _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hehe, that (or similar) was allways on my mind. In the past I started a project I named SDA (Smalltalk Developer Assistant) focused on lot of things that may be shortened as "Code Generation" :) as Genexus does. One more time, the lack of free time and the need of focus the time on payed projects did their work and the project is almost abandoned....but I agree that a tool that could do somethings automagically would help in 2 areas: 1. Attracting more people, and 2. Make the life of current Smalltalkers a bit more easy :) Germán. 2010/8/3 laurent laffont <laurent.laffont@gmail.com>:
On Mon, Aug 2, 2010 at 9:50 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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?
I would prefer: What kind of powerful task should be made easy out of the box ? - connect to a legacy MySQL database, send SQL requests and manipulate results - describe relations (a Library has many Books and Subscribers) -> generate -> Seaside (and/or Iliad or desktop) / view / controllers / models / database automatically setup. Plug in custom relations. - build an UI and create custom widgets. - deploy desktop and/or web app. and showcases + documentation. So Pharo can attracts new developpers who can say "wooww, so easy !". More developpers -> more business needs -> more contributions. Laurent
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- A scalable source code management system (MC gets very sloooow for large projects) - A change recovery mechanism that is not tedious (e.g., no mix of class definitions and do-its) - Better system integration: - OSProcess reliable and working for all major platforms - FFI/Alien; bindings to external libraries - A mature HTTP client (->WebClient looks good) - A decent Smalltalk library to interact with the file system - Clients for new DBs (was mentioned before) - OAuth (was mentioned before) Cheers, Adrian On Aug 2, 2010, at 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi,
- A scalable source code management system (MC gets very sloooow for large projects) - A change recovery mechanism that is not tedious (e.g., no mix of class definitions and do-its) - Better system integration: - OSProcess reliable and working for all major platforms - FFI/Alien; bindings to external libraries
+10
- A mature HTTP client (->WebClient looks good) - A decent Smalltalk library to interact with the file system
I am using FileSystem and it is quite nice. I would vote to integrate it in Pharo, if not in PharoCore. Doru
- Clients for new DBs (was mentioned before) - OAuth (was mentioned before)
Cheers, Adrian
On Aug 2, 2010, at 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "One cannot do more than one can do."
On Aug 3, 2010, at 11:09 AM, Tudor Girba wrote:
Hi,
- A scalable source code management system (MC gets very sloooow for large projects) - A change recovery mechanism that is not tedious (e.g., no mix of class definitions and do-its) - Better system integration: - OSProcess reliable and working for all major platforms - FFI/Alien; bindings to external libraries
+10
- A mature HTTP client (->WebClient looks good) - A decent Smalltalk library to interact with the file system
I am using FileSystem and it is quite nice. I would vote to integrate it in Pharo, if not in PharoCore.
Me too but it should handle utf8.
Doru
- Clients for new DBs (was mentioned before) - OAuth (was mentioned before)
Cheers, Adrian
On Aug 2, 2010, at 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?
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- A decent Smalltalk library to interact with the file system
I am using FileSystem and it is quite nice. I would vote to integrate it in Pharo, if not in PharoCore.
Me too but it should handle utf8.
I fixed that (the encoding issue of filenames) and many other things. Max discovered quite a few bugs while working on GitFS. Lukas -- Lukas Renggli www.lukas-renggli.ch
***Excellent!*** So we could really introduced it in 1.2. Let me know :) If some people want to join and help it can be done :) Stef On Aug 3, 2010, at 11:40 AM, Lukas Renggli wrote:
- A decent Smalltalk library to interact with the file system
I am using FileSystem and it is quite nice. I would vote to integrate it in Pharo, if not in PharoCore.
Me too but it should handle utf8.
I fixed that (the encoding issue of filenames) and many other things. Max discovered quite a few bugs while working on GitFS.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok guys you get a nice list of wishes. Now how could we proceed since ESUG is not the national swiss bank. What I envisioned is the following: - we select a topic like - improving webClient - OAuth (http://oauth.net/) - open-id (http://openid.net/) We know some excellent developers (that because of the economical situations of their countries) are also cheap. or you get bored and do not need to work to be payed and you can do them, this would be even better. We ask for an estimate. We create a pot where companies and esug as well can put money in. We do a large call. We wait that there is enough money in the pot and the project gets done. Does it make sense? else if you have magic powder let me know. Stef
How about including for each project a designated project sponsor/mentor/project manager who's job is liase between the developer(s) and the community and to ensure that a project focuses on the communities highest priorities. On 3 August 2010 10:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok guys you get a nice list of wishes. Now how could we proceed since ESUG is not the national swiss bank.
What I envisioned is the following: - we select a topic like - improving webClient - OAuth (http://oauth.net/) - open-id (http://openid.net/)
We know some excellent developers (that because of the economical situations of their countries) are also cheap. or you get bored and do not need to work to be payed and you can do them, this would be even better.
We ask for an estimate.
We create a pot where companies and esug as well can put money in. We do a large call.
We wait that there is enough money in the pot and the project gets done.
Does it make sense? else if you have magic powder let me know.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 3, 2010, at 11:40 AM, Nick Ager wrote:
How about including for each project a designated project sponsor/
sponsor is different from the mentor/project manager
mentor/project manager who's job is liase between the developer(s) and the community and to ensure that a project focuses on the communities highest priorities.
For now this is not the problem. :)
On 3 August 2010 10:30, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Ok guys you get a nice list of wishes. Now how could we proceed since ESUG is not the national swiss bank.
What I envisioned is the following: - we select a topic like - improving webClient - OAuth (http://oauth.net/) - open-id (http://openid.net/)
We know some excellent developers (that because of the economical situations of their countries) are also cheap. or you get bored and do not need to work to be payed and you can do them, this would be even better.
We ask for an estimate.
We create a pot where companies and esug as well can put money in. We do a large call.
We wait that there is enough money in the pot and the project gets done.
Does it make sense? else if you have magic powder let me know.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- a vector-based graphics engine, which can use GPU for fast rendering. :) -- Best regards, Igor Stasenko AKA sig.
Stef, Great news about the sockets rewrite!! On my wish list includes OpenSSL (Andreas appears to be making strides there??) and to see the end of polling for connections. Ideally, one could set the type of socket to be either TCP, UDP (for those who must), IrDA, etc. and have it work. It would also be nice to be able to get events when the other side closes the connection. Good network programming requires good error handling, and asynchronous activity. One must be able to reboot peers, turn off hubs, yank wires (name it) and not have the software hang. I don't think I care whether that is done with asynch sockets or blocking ones called on OS threads, but we're not done until it "never" hangs. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, August 07, 2010 10:50 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Poll: missing libraries to support business 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (15)
-
Adrian Lienhard -
Germán Arduino -
Igor Stasenko -
laurent laffont -
Levente Uzonyi -
Lukas Renggli -
Michael Roberts -
Miguel Enrique Cobá MartÃnez -
Nick Ager -
Norbert Hartl -
Philippe Marschall -
Schwab,Wilhelm K -
Sean P. DeNigris -
Stéphane Ducasse -
Tudor Girba