On 8/17/06, Andrew Borley [EMAIL PROTECTED] wrote:
Pete,
Sounds good to me, I'll definately be interested in reviewing if you have
something to show before tomorrow (Friday) afternoon (I'm on holiday for
the
week after that). The Python stuff I've been doing will need fitting in to
the
Still very much in experimental stage but I recognize your concerns.
ServiceProxy is an interesting example. It really belongs with the
implementation.cpp but is currently in the core. Do we need this at all for
other extensions or is there some other representation of the service?
more later...
On 8/18/06, Pete Robbins [EMAIL PROTECTED] wrote:
Still very much in experimental stage but I recognize your concerns.
ServiceProxy is an interesting example. It really belongs with the
implementation.cpp but is currently in the core. Do we need this at all
for
other extensions or is there some
On 18/08/06, Simon Laws [EMAIL PROTECTED] wrote:
Mmm, not sure. I was thinking that in the case of an extension that I
would
want the C++ SCA model to reflect all of the components and associated
services and references that appear in the SCA configuration (whether that
be through SCDL or
I've started playing around with loading extension libraries to support
other language extensions and so a wee bit of re-architecture has cpp
being an extension language. In other words I'm trying to make a core that
is not tied to cpp implementation. This core will roughly be a model loader
in
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension, name
the library and associate it with an implementation type? As a first
step at least, I think it would be great to have a very simple scheme
where you just drop a
On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote:
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension, name
the library and associate it with an implementation type? As a first
step at least, I think it would be
On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote:
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension, name
the library and associate it with an implementation type? As a first
step at least, I think it would be
On 16/08/06, Simon Laws [EMAIL PROTECTED] wrote:
On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote:
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension,
name
the library and associate it with an implementation
On 8/16/06, Andrew Borley [EMAIL PROTECTED] wrote:
On 8/16/06, Pete Robbins [EMAIL PROTECTED] wrote:
This looks like a really good plan. I have two questions:
1. Do we really need another XML file to describe the extension,
name
the library and associate it with an
This looks a reasonable approach. The runtime will need to call the
extension to load it's part of the model. So ModelLoader will need to know
which library to call for a particular implementation type. The mechanism
should be the same for all implementation types so the existing
On 8/15/06, Pete Robbins [EMAIL PROTECTED] wrote:
This looks a reasonable approach. The runtime will need to call the
extension to load it's part of the model. So ModelLoader will need to know
which library to call for a particular implementation type. The mechanism
should be the same for all
On 8/15/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Andrew Borley wrote:
Hi All,
I've been thinking a bit more about how we could do extensions.
Specifically, I've been working through what would be needed to add a
new
component language binding in to Tuscany. I'm basing this on
Hi All,
I've been thinking a bit more about how we could do extensions.
Specifically, I've been working through what would be needed to add a new
component language binding in to Tuscany. I'm basing this on adding support
for components written in Python, as this is a language that is widely
14 matches
Mail list logo
