Poll: missing libraries to support business

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Aug 7, 2010, at 2:00 PM, Philippe Marschall wrote:

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Saturday, August 07, 2010 10:50 AM
To: [hidden email]
Subject: Re: [Pharo-project] Poll: missing libraries to support business

On Aug 7, 2010, at 2:00 PM, Philippe Marschall wrote:

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project