Re: Sport and the future
- From: Ian Upright <ian-news@xxxxxxxxxxx>
- Date: Thu, 24 May 2007 07:41:07 GMT
Janko Mivsek <janko.mivsek@xxxxxxxxxx> wrote:
Hi Eliot, hi Bruce,
I also join Bruce to first define (let's say) an API for sockets (and
files and times) and later deal with implementation.
Hi Janko,
One of the things is, that we could end up pulling some C++ library off the
shelf, and plugging it in. Presto, we have an instance interface, and as
the C++ library is enhanced and evolves over time, so is our base library.
In such a case, it might make more sense to have nearly identical or very
similar class/method names as the C++ library, for consistency. And in such
a case, then this interface could potentially be quite different than what
we would design as the initial interface -- or create a significant
impedence mismatch that could be painful to deal with.
Cheers, Ian
I also understand---
you Eliot that implementation can influence back an API, but with having
that in mind we can overcome problems. For instance - using only
blocking socket calls we can "simulate" nonexistent concurrency on lower
level ...
Best regards
Janko
Eliot Miranda wrote:
Bruce Badger wrote:
Eliot,
I confess that I am more interested in the interfaces presented by the
libraries than the implementation of them, but I do think the FFI
approach makes a great deal of sense and could form a lower level set
of interfaces for doing all kinds of cool things.
I am hoping that Sport is like the irritating bit of grit that makes
an oyster grow a pearl. As a user of this pearl (or string of pearls
- one for each of sockets, files etc.) I only care that it's smooth,
consistent, looks nice and lasts. If the pearl makers get a better
way of making pearls too (e.g. FFI), then that's a big bonus.
What I would be uncomfortable about would be making Sport *depend* on
an FFI implementation ... or the other way around.
The problem is that basic facilities like threading determine how one
can write a given interface. This is especially true of things like
socket interfaces which involve asynchrony. IMO, if the community can
establish a basic level of FFI facilities that provide adequate
threading and callback facilities then the quality and portability of
Sport interfaces will be much enhanced.
I hope we get to talk more about FFIs at ESUG, Eliot. Will you be
there? :-)
Lugano in August. Hard to turn down. Right now I'm not planing on
attending. I have to first open my employer's purse strings ;)
All the best,
Bruce
cheers!
http://www.upright.net/ian/
.
- Follow-Ups:
- Re: Sport and the future
- From: Janko Mivšek
- Re: Sport and the future
- References:
- Sport and the future
- From: Bruce Badger
- Re: Sport and the future
- From: Eliot Miranda
- Re: Sport and the future
- From: Bruce Badger
- Re: Sport and the future
- From: Eliot Miranda
- Re: Sport and the future
- From: Janko Mivsek
- Sport and the future
- Prev by Date: Re: Sport and the future
- Next by Date: Re: Sport and the future
- Previous by thread: Re: Sport and the future
- Next by thread: Re: Sport and the future
- Index(es):
Relevant Pages
|
Loading