You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@d-haven.org> on 2004/03/18 15:55:34 UTC
[RRT] An interface is all you need
You know, that article that Bruce Eckel produced
(http://mindview.net/WebLog/log-0051) was thought provoking. Should
there be additional semantic meaning to an interface? I used to think
so, but now I don't.
An interface is all you can enforce in code, and all you should expect
the user to respect. But that's just me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
> I agree, but I also think that there are definite advantages to attaching
> rules to an interface. See the java collections framework as an example.
> Certainly, you could implement a remove method that actually adds, but
> that
> would be stupid. This is why interfaces with attached semantics should
> come
> with conformance test suites. I think that the whole point is that there
> is
> no way to 100% safeguard against misuse when using an interface (or even
> any
> non-final class).
Very good point with the collections example and interface can't enforce
code semantics just its syntax.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Jonathan Hawkes <jh...@adsnm.com>.
<snip type="excerpt">
The only semantics that are associated with an interface are the ones that
you enforce. A class can be an implementation of a particular interface, and
that class has its own semantics. You may require that all classes that
implement an interface follow a certain set of rules, but you can only
enforce those rules using tests that you apply outside of the compiling
environment. Your tests may be code walkthroughs or a conformance test
framework, but even if you feel strongly that your interface implies a
semantic contract, the only contract that is enforced by the language is
that any class that implements the interface will include the signatures in
that interface.
</snip>
I agree, but I also think that there are definite advantages to attaching
rules to an interface. See the java collections framework as an example.
Certainly, you could implement a remove method that actually adds, but that
would be stupid. This is why interfaces with attached semantics should come
with conformance test suites. I think that the whole point is that there is
no way to 100% safeguard against misuse when using an interface (or even any
non-final class).
----- Original Message -----
From: "Berin Loritsch" <bl...@d-haven.org>
To: <de...@avalon.apache.org>
Sent: Thursday, March 18, 2004 7:55 AM
Subject: [RRT] An interface is all you need
> You know, that article that Bruce Eckel produced
> (http://mindview.net/WebLog/log-0051) was thought provoking. Should
> there be additional semantic meaning to an interface? I used to think
> so, but now I don't.
>
> An interface is all you can enforce in code, and all you should expect
> the user to respect. But that's just me.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 02:54, Berin Loritsch wrote:
> To which I add, that component to container is only one area. There is
> also component to tool, as the example at the top of the list proves.
Wow... You may be closer to 'my camp' than I have imagined. So let's explore
my basic principles for a short while.
When I say "from component toward container", I mean;
1. The re-usable component is the center of gravity, not the container. The
container can change 100 times throughout the lifetime of a component.
2. For components to survive container changes the contracts must be tight
(just like they are in JavaBeans).
3. But contracts must be evolvable, replaceable and introduction of new ones.
Which means we need a way to define which contracts a component requires vs
would like (optional), meaning today's container must be able to know in
advance if it is compliant with the requirements.
4. Components are components before they are loaded into a container. That
means that there must be a 'primordial contract', which is externally
queryable about Identification, Versioning & Compliance.
5. There is no reason why Packaging is not set in contracts as well. New Ear,
War, Bar, Sar... Probably not. The fact that we won't need Jars in Jars,
probably Jar is fine, and adding a system to how 'other stuff' goes in there
in an expandable manner. Point is, it must be possible to define an "API
Documentation Contract" where an IDE can look at the 'external component' and
know how to integrate the API docs into the view.
Finally, Avalon Meta is barely much more than a utility. Jumping up and down
over its implementation is ridiculous. Jumping up and down over the @tags
that exists is somewhat relevant, but they will evolve.
Jumping up any down over the external Meta representation a waste of time.
Avalon Meta 1.0 (currently in Merlin) is a specification. We need a system,
where that can be slapped on to a component (externally) so that a
future-compatible container can query (as in reading an embedded file in the
Jar) the component about if that is a Requirement or an Optional Requirement,
meaning "What to do if I, the container, is not compliant with the
requiment?"
THIS is important.
An all-encompassing specification won't work, just like all-encompassing
applications doesn't work, or all-encompassing classes doesn't work.
Decomposition is key.
Are we on the same page?
If we are, we can proceed with the important stuff, instead of petty arguments
over container implementation details and meta tag names.
Niclas
> > Why do I ask so many questions?
>
> Because we never learn if we don't.
It was a parody on your initial post :o) being a pre-teen kid, who only
answer questinos with new questions...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Friday 19 March 2004 02:30, Berin Loritsch wrote:
>
>>Granted, the same type of thing can be done using attributes instead of
>>naming conventions. The attributes would prove more flexible as well
>>because they can include more information than the general "Type" that is
>>acceptable. That would minimize the occurance of
>>IllegalArgumentExceptions, etc. because the tool would then be able to
>>provide a control that does not allow the user to input bad information.
>
>
> Is this the first time two of us can agree? Wouldn't that be something to
> celebrate? Or are you just being sarcastic?
We agree on this. It isn't the first time. The thing is in many respects
we agree on many things, just not on the methodology most times.
>>However, in order to tool that, the current Avalon Meta package is woefully
>>unequipped. Then again, I am sure there are a number of other ways to
>>accomplish the same goal. But, as you say, it comes down to the tools that
>>enable the user to do what they need.
>
> Do I think Avalon Meta in the current shape is a final solution? Have I not
> made it obvious that my angle is from the component towards the container,
> not the other way like everyone else?
I would imagine the answers to be the following:
1) No.
2) Yes.
To which I add, that component to container is only one area. There is also
component to tool, as the example at the top of the list proves.
There are many aspects in which a tool can assist developers that have nothing
to do with the container. That is why I feel that restricting the meta info
to only that recognized by the container is a mistake. I do feel that there
should be a set of meta-info that the container recognizes and that should be
pretty much set in as much stone as Avalon Framework. However I also feel that
there is value in allowing other attributes to be used for components that work
with tools or provide instrumentation hints.
When you constrain your set of gathered attributes to only the ones recognized
by the container, you lose out on a large group of enhancements that can provide
real value add. I am not saying the container should recognize all these extra
attributes or even worry about them. The contract between the component and the
container is just that. It should remain at that. There can be contracts
between a component and a tool. Contracts between a component and an add on
to the container. Does that mean that we are now restricted to that container,
or just that we need the add on to work in other containers?
The point I am trying to get to is that the contracts should be limited to
exactly what they are. Just how much information does a component have to
provide to the container to be useful? IMO, it is limited to the services
provided, and the dependencies needed. Everything else is extra. Does it
mean that it is not useful? No. It can be used for component validation
and verification. It can be used for a number of things. So, if I have a
component with the minimal amount of information supplied, I shouldn't have
to worry about it being rejected because I didn't supply validation tags.
Do you see what I am getting at?
> Why do I ask so many questions?
Because we never learn if we don't.
> Niclas?
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 02:30, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> Why should we event have to worry about a wrapper?
Can I worry about the wrapper since it adds value?
> Granted, the same type of thing can be done using attributes instead of
> naming conventions. The attributes would prove more flexible as well
> because they can include more information than the general "Type" that is
> acceptable. That would minimize the occurance of
> IllegalArgumentExceptions, etc. because the tool would then be able to
> provide a control that does not allow the user to input bad information.
Is this the first time two of us can agree? Wouldn't that be something to
celebrate? Or are you just being sarcastic?
> However, in order to tool that, the current Avalon Meta package is woefully
> unequipped. Then again, I am sure there are a number of other ways to
> accomplish the same goal. But, as you say, it comes down to the tools that
> enable the user to do what they need.
Do I think Avalon Meta in the current shape is a final solution? Have I not
made it obvious that my angle is from the component towards the container,
not the other way like everyone else?
Why do I ask so many questions?
Niclas?
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Friday 19 March 2004 01:24, Berin Loritsch wrote:
>
>
>>How about all that code that was designed with JavaBeans specs in mind?
>
>
> What about it?
Are they not components after a fashion? At least according to Sun.
>>Will you be able to support that too? If so, to what level? How much
>>busy work does a person have to do to make that JavaBean that does what
>>I need work in the new Avalon?
>
> How often does he have to do it? How many people have to do the wrapper, and
> press Publish in their IDE?
Why should we event have to worry about a wrapper?
>>Oh, is that not part of the re-use we are talking about?
>
> Why not? Btw, isn't JavaBeans to constricting for your taste, all these naming
> conventions, semantics, meta information and what not?
If you really think that about me you have totally missed the point of
everything I have said and our time is wasted. My appologies.
>>Heck, you know that a modern J2EE container can provide you with all the
>>configuration points for a JDBC DataSource component? How? Well, because
>>of the JavaBeans Spec.
>
> You probably know more about JDBC than I do, what is a DataSource component?
> Does it happen to be that a DataSource component have to follow certain
> rules? You say JavaBeans, and might it not be that there are some stuff
> implied in the getXyz() names? Via BeanInfo (what is that by the way, meta
> perhaps?)?
The DataSource component is javax.sql.DataSource. All J2EE compatible drivers
have something that implements this interface. However, directly on the
implementing class is all the setters and getters for the individual component
configurations. Essentially JavaBeans is a set of naming guidelines to enable
reflective setting of properties. The reason for the naming conventions can
then translate into something easy to tool.
Granted, the same type of thing can be done using attributes instead of naming
conventions. The attributes would prove more flexible as well because they can
include more information than the general "Type" that is acceptable. That would
minimize the occurance of IllegalArgumentExceptions, etc. because the tool would
then be able to provide a control that does not allow the user to input bad
information.
However, in order to tool that, the current Avalon Meta package is woefully
unequipped. Then again, I am sure there are a number of other ways to
accomplish the same goal. But, as you say, it comes down to the tools that
enable the user to do what they need.
>>There are dozens of tools around that do that. What value are we adding?
>
> Do I have to answer it?
Eventually. To users, not me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 01:24, Berin Loritsch wrote:
> How about all that code that was designed with JavaBeans specs in mind?
What about it?
> Will you be able to support that too? If so, to what level? How much
> busy work does a person have to do to make that JavaBean that does what
> I need work in the new Avalon?
How often does he have to do it? How many people have to do the wrapper, and
press Publish in their IDE?
> Oh, is that not part of the re-use we are talking about?
Why not? Btw, isn't JavaBeans to constricting for your taste, all these naming
conventions, semantics, meta information and what not?
> Heck, you know that a modern J2EE container can provide you with all the
> configuration points for a JDBC DataSource component? How? Well, because
> of the JavaBeans Spec.
You probably know more about JDBC than I do, what is a DataSource component?
Does it happen to be that a DataSource component have to follow certain
rules? You say JavaBeans, and might it not be that there are some stuff
implied in the getXyz() names? Via BeanInfo (what is that by the way, meta
perhaps?)?
> There are dozens of tools around that do that. What value are we adding?
Do I have to answer it?
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 01:31, Jonathan Hawkes wrote:
> > Stephen McConnell wrote:
> > >> Let's make the Pipe dream become a Reality, even if I am going to die
> > >> trying. The potential benefits are too vast to stop trying.
> > >
> > > +1^84
>
> You are aware that this is still a +1? :)
ROTFL... Someone who is really bright ! It didn't cross my mind.
+7629178398712389712398723^0
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Stephen McConnell <mc...@apache.org>.
Jonathan Hawkes wrote:
>>Stephen McConnell wrote:
>>
>>
>>>>Let's make the Pipe dream become a Reality, even if I am going to die
>>>>trying. The potential benefits are too vast to stop trying.
>>>
>>>+1^84
>
>
> You are aware that this is still a +1? :)
Yep - but is a really *big* +1.
;-)
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> Stephen McConnell wrote:
>
> >> Let's make the Pipe dream become a Reality, even if I am going to die
> >> trying. The potential benefits are too vast to stop trying.
> >
> > +1^84
You are aware that this is still a +1? :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
>> Let's make the Pipe dream become a Reality, even if I am going to die
>> trying. The potential benefits are too vast to stop trying.
>
> +1^84
>
> Anything less just doesn't cut it!
How about all that code that was designed with JavaBeans specs in mind?
Will you be able to support that too? If so, to what level? How much
busy work does a person have to do to make that JavaBean that does what
I need work in the new Avalon?
Oh, is that not part of the re-use we are talking about?
Then if it is included (or at least can be included), do we really need
all this other stuff? You see, there comes a point of diminishing returns.
If the JavaBeans folks were as brilliant as some people claim, then what
value are we adding? There are tools that work with those off the bat.
Heck, you know that a modern J2EE container can provide you with all the
configuration points for a JDBC DataSource component? How? Well, because
of the JavaBeans Spec.
There are dozens of tools around that do that. What value are we adding?
P.S. I know all the answers to that question, but I am not the one you need
to sell on it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Friday 19 March 2004 00:39, Berin Loritsch wrote:
<snip/>
>>Therefore, the only time there is
>>semantic meaning is when there is code. In this case, the java interface
>>and the compliance tests are the only thing with meaning. The meta
>>information only gains meaning when the container respects it and acts
>>accordingly.
>
>
> Meta has an enormous importance to bring re-use to the next level. Tools, man,
> tools!
>
>
>>Perhaps I am jaded by the fact that up to now near
>>100% or even 80% re-use has been a pipe dream.
>
>
> Let's make the Pipe dream become a Reality, even if I am going to die trying.
> The potential benefits are too vast to stop trying.
+1^84
Anything less just doesn't cut it!
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Meta has an enormous importance to bring re-use to the next level. Tools,
> man,
> tools!
Intelligence in the animal kingdom is defined as the capacity of an organism
to use tools.
> > Perhaps I am jaded by the fact that up to now near
> > 100% or even 80% re-use has been a pipe dream.
>
> Let's make the Pipe dream become a Reality, even if I am going to die
> trying.
> The potential benefits are too vast to stop trying.
+1
This is not a pipe dream - reuse is possible it just takes some radical
thinking. Oh and subversion too :-). Ok I know its unrelated excuse me.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 00:39, Berin Loritsch wrote:
> > 3. Service != interface -=-=> The Service carries with it a lot more
> > than the Java interface, incl. the semantics, meta information,
> > documentation, and preferably compliance tests.
>
> Yeah, I was in that camp too. Think about it though. You cannot impose
> semantic meaning without actual code.
On the contrary! Without the semantic meaning, it is not possible to do the
implementation. Otherwise you are "Coding by Coincidence" as someone coined
the expression.
Example;
Please provide a working implementation (I have a client component that uses
several other implementations already) for
public interface GjkhadfUolqwknj
{
float ouihndoubne( String lwwqen, float ppqtrej );
}
For the sake of argument, I have obfuscated the names, since names may carry
implied semantic meaning.
> Therefore, the only time there is
> semantic meaning is when there is code. In this case, the java interface
> and the compliance tests are the only thing with meaning. The meta
> information only gains meaning when the container respects it and acts
> accordingly.
Meta has an enormous importance to bring re-use to the next level. Tools, man,
tools!
> Perhaps I am jaded by the fact that up to now near
> 100% or even 80% re-use has been a pipe dream.
Let's make the Pipe dream become a Reality, even if I am going to die trying.
The potential benefits are too vast to stop trying.
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 01:19, Berin Loritsch wrote:
> I see little evidence.
Here is the evidence;
http://marc.theaimsgroup.com/?l=avalon-dev&m=107940014832041&w=2
Maybe you need a coffin too :D
Cheers
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>> Berin:
>>
>> Change is happening.
>> Seems to me like you not planning for it.
>> Send me you address and I'll post you some nails.
>>
>
> Hee, hee. Ha, ha. Ho hum.
>
> I see little evidence.
"denial"
An unconscious defense mechanism characterized by refusal to
acknowledge painful realities, thoughts, or feelings.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Berin Loritsch <bl...@d-haven.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>> Change happens, if you don't plan for it, you are essentially nailing
>> your
>> own coffin.
>
>
> Berin:
>
> Change is happening.
> Seems to me like you not planning for it.
> Send me you address and I'll post you some nails.
>
Hee, hee. Ha, ha. Ho hum.
I see little evidence.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Change happens, if you don't plan for it, you are essentially nailing your
> own coffin.
Berin:
Change is happening.
Seems to me like you not planning for it.
Send me you address and I'll post you some nails.
:-)
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Stephen McConnell <mc...@apache.org>.
Jonathan Hawkes wrote:
> You know, this discussion has been interesting. As Berin (and the
> aforementioned article) pointed out, an interface is a very loose contract.
> It may have semantic meaning attached, but that meaning cannot be natively
> enforced in the Java programming language. Thus, we have conformance tests
> for interfaces that require a more exacting definition. So, should a
> container directly support such additional contracts?
Absolutely fundamentally no question - YES.
> I think that it would
> be a neat idea if we had the option.
We have the option.
We also have the implementation.
> This would be especially nice for running non-trusted components. In
> addition to defining security policies under which they are executed, they
> could be required to pass conformance tests (if applicable) before
> deployment.
>
> What do you guys think?
Ummm ....
It's a no-brainer.
+1
> Jonathan Hawkes
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 01:02, Leo Sutic wrote:
> The problem is that the conformance testing either:
>
> 1. Will have side effects
>
> or
>
> 2. Will not exercize the live code
>
> Since the container can't always set up a dummy
> environment. (And then we have to validate the dummy
> environment.)
I brought up component testing earlier, and have been looking at it.
The conclusion is pretty much the above, but that there are areas of
compliance that can be tested. However, few here are in the mind-set to
discuss these areas, so I will leave it out for now.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> OK, so in effect it is a pleaseTestYourself() for the component,
> since we don't really know what code is being run. (I.e. untrusted
> component runs good code from 0900-1500, and bad code the rest
> of the day.)
>
> Sounds good in theory, but a real pain in practice.
Most likely :) Just an RT.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
>
> > Well... yes, but not by the container. When my container deploys a
> > DatabaseConnection component, I don't want it to validate that
> > dropDatabaseAndPurgeAllBackups() works as advertised.
>
> Of course. That is why
>
> 1. Conformance tests are optional (a feature)
> 2. The conformance test suite would no doubt be only a subset
>
> I imagine that these tests would only be useful if running in
> "debug" mode or "untrusted" mode.
OK, so in effect it is a pleaseTestYourself() for the component,
since we don't really know what code is being run. (I.e. untrusted
component runs good code from 0900-1500, and bad code the rest
of the day.)
Sounds good in theory, but a real pain in practice.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> Well... yes, but not by the container. When my container
> deploys a DatabaseConnection component, I don't want it
> to validate that dropDatabaseAndPurgeAllBackups() works
> as advertised.
Of course. That is why
1. Conformance tests are optional (a feature)
2. The conformance test suite would no doubt be only a subset
I imagine that these tests would only be useful if running in "debug" mode
or "untrusted" mode.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> On Friday 19 March 2004 02:13, Alex Karasulu wrote:
>
>>Perhaps this should be the responsibility of the component repository
>>as a decorating service. Components get flagged with the tested and
>>passed attribute to make them worthy. But putting this functionality
>>into a container is a little too heavy IMO.
>
>
> That is another interesting aspect; Component Certification.
>
> Not that we should certify components, or that we define the certification
> spec, BUT that we define how to attach the Compliance Certificates to the
> component.
+1
> Niclas
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Thursday, March 18, 2004 1:17 PM
>
> On Friday 19 March 2004 02:13, Alex Karasulu wrote:
> > Perhaps this should be the responsibility of the component repository
> > as a decorating service. Components get flagged with the tested and
> > passed attribute to make them worthy. But putting this functionality
> > into a container is a little too heavy IMO.
>
> That is another interesting aspect; Component Certification.
Yes well characterized term: Component Certification.
> Not that we should certify components, or that we define the certification
> spec, BUT that we define how to attach the Compliance Certificates to the
> component.
We can then search enable a repo so queries for certified components can
occur. Also these flags on a component can also be used to find instances
of the service in a registry. There was a nice diagram of the repo and
Registry role that Stephen had put up a while back. I'll post it if I can
find it in a couple of minutes - otherwise use your imagination.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 19 March 2004 02:13, Alex Karasulu wrote:
> Perhaps this should be the responsibility of the component repository
> as a decorating service. Components get flagged with the tested and
> passed attribute to make them worthy. But putting this functionality
> into a container is a little too heavy IMO.
That is another interesting aspect; Component Certification.
Not that we should certify components, or that we define the certification
spec, BUT that we define how to attach the Compliance Certificates to the
component.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> CPAN (the Perl repository) has this nice feature where when you
> download & install a perl module, it will run unit tests to
> confirm that it is working correctly on your system.
>
> For example, when I download and install MySQL drivers they
> will run some tests against a temporary MySQL database
> to verify that everything is OK.
That is very cool. BTW have you been tracking any of the emails going
around on the repository@ list about CJAN?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
CPAN (the Perl repository) has this nice feature where when you
download & install a perl module, it will run unit tests to
confirm that it is working correctly on your system.
For example, when I download and install MySQL drivers they
will run some tests against a temporary MySQL database
to verify that everything is OK.
/LS
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
> >
> > they could be required to pass
> > conformance tests (if applicable) before deployment.
> >
> > What do you guys think?
>
> Well... yes, but not by the container. When my container
> deploys a DatabaseConnection component, I don't want it
> to validate that dropDatabaseAndPurgeAllBackups() works
> as advertised.
>
+1
Perhaps this should be the responsibility of the component repository
as a decorating service. Components get flagged with the tested and
passed attribute to make them worthy. But putting this functionality
into a container is a little too heavy IMO.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
>
> they could be required to pass
> conformance tests (if applicable) before deployment.
>
> What do you guys think?
Well... yes, but not by the container. When my container
deploys a DatabaseConnection component, I don't want it
to validate that dropDatabaseAndPurgeAllBackups() works
as advertised.
Conformance testing should be done by the component
developer prior to distributing the component.
The problem is that the conformance testing either:
1. Will have side effects
or
2. Will not exercize the live code
Since the container can't always set up a dummy
environment. (And then we have to validate the dummy
environment.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Jonathan Hawkes <jh...@adsnm.com>.
You know, this discussion has been interesting. As Berin (and the
aforementioned article) pointed out, an interface is a very loose contract.
It may have semantic meaning attached, but that meaning cannot be natively
enforced in the Java programming language. Thus, we have conformance tests
for interfaces that require a more exacting definition. So, should a
container directly support such additional contracts? I think that it would
be a neat idea if we had the option.
This would be especially nice for running non-trusted components. In
addition to defining security policies under which they are executed, they
could be required to pass conformance tests (if applicable) before
deployment.
What do you guys think?
Jonathan Hawkes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Thursday 18 March 2004 22:55, Berin Loritsch wrote:
>
>>You know, that article that Bruce Eckel produced
>>(http://mindview.net/WebLog/log-0051) was thought provoking. Should
>>there be additional semantic meaning to an interface? I used to think
>>so, but now I don't.
>>
>>An interface is all you can enforce in code, and all you should expect
>>the user to respect. But that's just me.
>
>
> 1. I start thinking you are on drugs. :o)
Sufedrin to be exact... ;D
>
> 2. As Jonathan points out, what is the method .remove() supposed to do? Start
> WarCraft and reformat the hard disk?
Did you catch the link to the WIKI describing enabling and restrictive
approaches? There are two schools of thought here that we ascribe to.
Neither are wrong, but they come from opposite minds.
Basically if someone is a true anarchist (not me mind you) then they will
find a way to circumvent all the controls you have put in place. Eventually,
you can get to the place where all these preventative controls can actually
constrain someone who is trying to solve a legitimate problem so much that
they cannot use the project.
One of the key points there was that the actual occurance of abuse is lower
than many people seem to attribute. I like software to enable me, not restrict
me. Granted, if there is something truly damning that I can do inadvertently,
I would expect there to be problems and for the framework to alert me to it.
However, if the framework is designed properly I should really know when I am
circumventing it.
> 3. Service != interface -=-=> The Service carries with it a lot more than
> the Java interface, incl. the semantics, meta information, documentation, and
> preferably compliance tests.
Yeah, I was in that camp too. Think about it though. You cannot impose
semantic meaning without actual code. Therefore, the only time there is
semantic meaning is when there is code. In this case, the java interface and
the compliance tests are the only thing with meaning. The meta information
only gains meaning when the container respects it and acts accordingly.
Don't get me wrong, I am for a complete enough definition of a service to
actually get some work done, but I don't want to have to remember a hundred
different things to make it work.
> You can't call yourself a proponent of re-use... Especially since re-use is
> also a restriction, and you seem to take everything to the extreme edge, such
> restriction can't be good, so don't use it. Make your own bolts to fit your
> holes, will ya...
Well, I can call myself one, but we have a difference of oppinion on what
constitutes re-use. Perhaps I am jaded by the fact that up to now near 100%
or even 80% re-use has been a pipe dream. There are many reasons for that.
Some of them come down to legal/monetary/non-code related issues. Some of
them come down to ignorance of what is available. More often than not, it
comes down to something being close to what is needed, but not quite. So
I take a more pragmatic approach and realize I can only re-use so much.
Change happens, if you don't plan for it, you are essentially nailing your
own coffin. I like re-use, but I also like to do so in a way that can be
managed and provide for future growth.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
Hi,
Getting in late to this conversation but better late than never.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> On Thursday 18 March 2004 22:55, Berin Loritsch wrote:
> > You know, that article that Bruce Eckel produced
> > (http://mindview.net/WebLog/log-0051) was thought provoking. Should
> > there be additional semantic meaning to an interface? I used to think
> > so, but now I don't.
> >
> > An interface is all you can enforce in code, and all you should expect
> > the user to respect. But that's just me.
>
> 1. I start thinking you are on drugs. :o)
>
> 2. As Jonathan points out, what is the method .remove() supposed to do?
> Start
> WarCraft and reformat the hard disk?
ROTFL! I think Jonathan made a good point with the collections example.
An interface is not everything.
> 3. Service != interface -=-=> The Service carries with it a lot more
> than
> the Java interface, incl. the semantics, meta information, documentation,
> and
> preferably compliance tests.
+1
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RRT] An interface is all you need
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 18 March 2004 22:55, Berin Loritsch wrote:
> You know, that article that Bruce Eckel produced
> (http://mindview.net/WebLog/log-0051) was thought provoking. Should
> there be additional semantic meaning to an interface? I used to think
> so, but now I don't.
>
> An interface is all you can enforce in code, and all you should expect
> the user to respect. But that's just me.
1. I start thinking you are on drugs. :o)
2. As Jonathan points out, what is the method .remove() supposed to do? Start
WarCraft and reformat the hard disk?
3. Service != interface -=-=> The Service carries with it a lot more than
the Java interface, incl. the semantics, meta information, documentation, and
preferably compliance tests.
You can't call yourself a proponent of re-use... Especially since re-use is
also a restriction, and you seem to take everything to the extreme edge, such
restriction can't be good, so don't use it. Make your own bolts to fit your
holes, will ya...
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RRT] An interface is all you need
Posted by Alex Karasulu <ao...@bellsouth.net>.
Damn more reading ...
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Berin Loritsch
> Sent: Thursday, March 18, 2004 9:56 AM
> To: dev@avalon.apache.org
> Subject: [RRT] An interface is all you need
>
> You know, that article that Bruce Eckel produced
> (http://mindview.net/WebLog/log-0051) was thought provoking. Should
> there be additional semantic meaning to an interface? I used to think
> so, but now I don't.
>
> An interface is all you can enforce in code, and all you should expect
> the user to respect. But that's just me.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org