ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | proactive List | Febuary 2004 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [fractal] comments on the Fractal 2.0 specification draft

forwarded from the fractal mailing list

----------  Forwarded Message  ----------

Subject: Re: [fractal] comments on the Fractal  2.0 specification draft
Date: Tuesday 03 February 2004 21:30
From: Jean-Bernard Stefani <Jean-Bernard.Stefani@xxxxxxxxxxxx>
To: Matthieu.Morel@xxxxxxxxxxxxxxx
Cc: fractal@xxxxxxxxxxxxx


I cncur with Eric's response except on point 4: agreed, in general
collection interfaces can only be created lazily for there is a priori an
infinite number of them. However I think we can remove the bland assertion
'these interfaces are created lazily' with a small paragraph explaining
this in more detail.

On your implementation for Proactive, it would be nice if we could see how
best to make your implementation and Julia converge. My sentiment is that
we should have one toolkit for supporting Fractal components in Java and
that if specific needs appear, we should be able to acomodate them as a
proper extension to the toolkit. What do you think ?



At 14:07 +0100 2/02/04, Matthieu Morel wrote:
>Bonjour a tous,
>We are currently working on an implementation of the Fractal model for the
>ProActive library, and here are a few comments about the draft specification
>of Fractal :
>1. new kinds of components
>In our implementation, we have defined a new kind of component : parallel
>components. It is a specialization of the composite components, where all
>enclosed components are of the same type than the enclosing component.
>The bindings are performed - possibly automatically - between the enclosing
>component and the enclosed components, linking interfaces of the same type.
>Maybe this new kind of component could be envisaged somewhere in the spec,
> as an extension possibility for example?
>2. listFc method
>We also agree, as was suggested in a previous message, that the listFc
> method (of the BindingController) has a confusing name, as it only returns
> client interfaces, but we understand it cannot be changed easily.
>Nevertheless, could this particularity be outlined in the javadoc?
>3. Attribute control in 4.2.
>should we read " a component that wants an AttributeController interface
>for a
>read only string attribute foo must provide a sub interface of this
> interface containing the following operation void setFoo(string foo)"?
>I wonder if we shouldn't read getFoo, as the attribute is read-only?
>Same comment for the write-only attribute.
>4. collective interfaces
>In the specification (6.1), it is written "these interfaces are created
>You impose a constraint on the creation of the collective interfaces (lazy
>instantiation). Couldn't this constraint be removed? You could then write
>"these interfaces *can* be created lazily".
>PS : We will soon post our review of the new ADL specification
>You receive this message as a subscriber of the fractal@xxxxxxxxxxxxx
>mailing list.
>To unsubscribe: mailto:fractal-unsubscribe@xxxxxxxxxxxxx
>For general help: mailto:sympa@xxxxxxxxxxxxx?subject=help
>ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

Jean-Bernard STEFANI
Research Director, SARDES Project
INRIA Rhône-Alpes
655, avenue de l'Europe
38334 St Ismier Cedex
tel : +33 (0)4 76 61 52 57
fax : +33 (0)4 76 61 52 52
email : Jean-Bernard.Stefani@xxxxxxxx


<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.