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...@apache.org> on 2003/07/15 22:03:40 UTC
[RT] Simplifying the Meta Suite
Currently, we have the following jars:
meta-api -> The core API for interpreting meta info
meta-spi -> Interfaces for reading/writing meta info
meta-impl -> Different readers and writers for meta info, and a verifier
meta-tools -> ANT additions to generate meta-info, etc.
meta-plugin -> Maven plugin to directly work with meta-info
Overall I don't have a problem with this. However, I do have a few questions
as it is now defined:
1) What, precisely, is the difference between a Service and a Type?
- A Service defines contracts for client/component communication
- Programmatically what is the difference?
2) Why are the readers and serializers for types and services separate
and distinct?
- Aren't services a function of what is exported by a type?
- Are their information recorded separately, hense lending support to
the notion that an interface defines a service?
3) Don't we want many readers, but only one official writer?
- Do we want XML (safe between JRE changes)?
- Do we want Serialization?
- Do we want something else intirely (i.e. bytecode embedding)?
4) How about allowing for extensions to be incorporated into the reader/writers/
verifiers?
5) What do we have separate readers/writers for services and types?
- I believe it would be cleaner to have one for each.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Simplifying the Meta Suite
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> Berin Loritsch wrote:
>>
>>>
>>> 3) Don't we want many readers, but only one official writer?
>>
>>
>> No. We want many readers are a snall number of endoreced writers.
>>
>>>
>>> - Do we want XML (safe between JRE changes)?
>>
>>
>> Yes.
>>
>>>
>>> - Do we want Serialization?
>>
>>
>> Yes.
>>
>>>
>>> - Do we want something else intirely (i.e. bytecode embedding)?
>>
>>
>> Maybe.
>
>
>
> I don't agree here. The *core* definition should have *one* way of
> defining the meta info. I'm thinking distributable here.
I disagree. The XML provides a good stable human and machine readable
for. But you want to be able to pass this form around between tools and
distributed environments. XML is lame for that - but a serialized form
is great.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Simplifying the Meta Suite
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
> Berin Loritsch wrote:
>
>>
>> 3) Don't we want many readers, but only one official writer?
>
> No. We want many readers are a snall number of endoreced writers.
>
>>
>> - Do we want XML (safe between JRE changes)?
>
> Yes.
>
>>
>> - Do we want Serialization?
>
> Yes.
>
>>
>> - Do we want something else intirely (i.e. bytecode embedding)?
>
> Maybe.
I don't agree here. The *core* definition should have *one* way of
defining the meta info. I'm thinking distributable here.
The special case would be something where we distribute services.
The thing is that any one of these can be easily used for that purpose.
The serialization has the benefit of no interpretation, but of course
we could take advantage of JDK 1.4's XML serialization.... Probably
10 times as verbose as necessary.
We might want version info for the serialization so that as the
XML/binary persistence can be properly identified and interpreted
if there are incompatible changes.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Simplifying the Meta Suite
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Currently, we have the following jars:
>
> meta-api -> The core API for interpreting meta info
> meta-spi -> Interfaces for reading/writing meta info
> meta-impl -> Different readers and writers for meta info, and a
> verifier
> meta-tools -> ANT additions to generate meta-info, etc.
> meta-plugin -> Maven plugin to directly work with meta-info
>
>
> Overall I don't have a problem with this. However, I do have a few
> questions
> as it is now defined:
>
> 1) What, precisely, is the difference between a Service and a Type?
> - A Service defines contracts for client/component communication
> - Programmatically what is the difference?
A Service is a meta-info object that describes a service.
A Type is a meta-info object that describes a component implementation.
The default notion of a service is a java interface class. The Service
meta-info class provides support for the attribution of a version and
supplimentary attributes to that defintion.
>
>
> 2) Why are the readers and serializers for types and services separate
> and distinct?
> - Aren't services a function of what is exported by a type?
Typically - yes. But this is not always the case. I have services that
arte produced by non-components. I have components that produce
services indirectly (ie. CORBA POA based servant activators). The
seperation of Service and Type ensures that the meta-model does not make
the assumption that services can only be produced by avalon component
implementations.
>
> - Are their information recorded separately, hense lending support to
> the notion that an interface defines a service?
An interface does define a service.
A Service suppliments that information.
>
>
> 3) Don't we want many readers, but only one official writer?
No. We want many readers are a snall number of endoreced writers.
>
> - Do we want XML (safe between JRE changes)?
Yes.
>
> - Do we want Serialization?
Yes.
>
> - Do we want something else intirely (i.e. bytecode embedding)?
Maybe.
>
>
> 4) How about allowing for extensions to be incorporated into the
> reader/writers/
> verifiers?
Lots of thinking and lots of work to be done before answering that.
This is the sort of thing that should be experimented with (but not
included in the core at this time) - but I'm about to dive and and take
a look at what you have just added.
>
>
> 5) What do we have separate readers/writers for services and types?
> - I believe it would be cleaner to have one for each.
You want seperate writers because a custom service writer does not need
to know about Type details. As far as readers are concerned, the Type
and Service readers could be converged into a single interface.
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org