Re: Registry proposal, was: Delivery Status Notification (Failure)

Wed, 30 Aug 2006 10:00:23 -0700

I had one additional comment: is there a reason we have to use the ".INSTANCE" approach to locating the default Provider? 

Jim

On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/tests attached 
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be not thinking 
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for following 
attachments. Thank Ant.
There's "neither* EMF *nor* Eclipse dependency. impl/EMF and impl/ Eclipse 
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have info to find 
Class Diagram and others.

I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling point of 
this generic registry.
Tailoring can be done based on the framework/infrastructure/ fundation (as 
Raymond commented).
There're at least two ways to provide strong interfaces over this registry. 
2-1. Delegating
new StrongInterface()
{
 public MySymbol getMySymbol (QName qName)
 {
   return mySymbolSpace.resolve( qName);
 }
}
2-2. Extending
 class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface

Thank everyone for all comments.

On 8/30/06, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

Please see my comments in line.

Thanks,
Raymond

----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification (Failure) 


>I might be missing something as well but I didn't see any code
under  impl
>at all

I guess it's for the API/SPI review first.

>
> I'm also with Ant in thinking we should not have a dependency on EMF. 
>

From the javadoc, I don't see the EMF dependencies.

> I'd also add that I found it difficult to grok the
relationships  between
> all the interfaces and inner-interfaces and how the behaviour would > integrate with Map semantics - for example, how does this differ from 
> just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it should be 
first-class interface instead of being inner.

I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very problematic 
to
me. When we run out of names, it means to me we don't model it correctly. 

A class diagram would be of great help for us.

>
> I'm also not convinced that throwing everything (all types of
stuff)  into
> one central registry model is a good way to go. I can see a lot  of
> benefit in having more specialized interfaces tailored for each type of 
> stuff.
I guess we can reuse the same infrastrcture backed by the generic registry 
but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.

>
> --
> Jeremy
>
> On Aug 30, 2006, at 4:10 AM, ant elder wrote:
>
>> Having this attached to a JIRA is fine, thats preferred over sending 
>> attachments to the dev list.
>>
>> Thanks for all this, I've only just started looking but it looks very 
>> comprehensive, a lot more than I was expecting 8-). I've a
few  questions
>> so
>> far. Firstly you didn't click the button granting license of the code 
to
>> the
>> ASF, was that an oversight? The readme talks about some test examples 
>> and
>> samples showing how to use the registry but the test folders
don't  seem
>> to
>> be included in the zip? From the brief look it wasn't clear to me if 
the
>> registry will require EMF, hopefully it doesn't?
>>
>> Thanks,
>>
>>   ...ant
>>
>> On 8/30/06, Yang ZHONG <[EMAIL PROTECTED]> wrote:
>>>
>>> Neither tuscany-dev nor infra takes my email with attachment, so I've 
>>> attached file for review into
>>> http://issues.apache.org/jira/browse/TUSCANY-677
>>>
>>> Sorry for the inconvenience and thanks for any comment.
>>>
>>> On 8/30/06, Mail Delivery Subsystem <mailer- [EMAIL PROTECTED]> 
>>> wrote:
>>> >
>>> > This is an automatically generated Delivery Status Notification
>>> >
>>> > Delivery to the following recipient failed permanently:
>>> >
>>> >     [EMAIL PROTECTED]
>>> >
>>> > Technical details of permanent failure:
>>> > PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
>>> is spam
>>> > (body)
>>> >
>>> >   ----- Original message -----
>>> >
>>> > Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
>>> >        Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
>>> > Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
>>> -0700
>>> (PDT)
>>> > Message-ID:
>>> <[EMAIL PROTECTED]
>>> >
>>> > Date: Wed, 30 Aug 2006 03:06:41 -0700
>>> > From: "Yang ZHONG" <[EMAIL PROTECTED]>
>>> > To: tuscany-dev@ws.apache.org
>>> > Subject: Re: Auto discovering WSDL
>>> > Cc: [EMAIL PROTECTED]
>>> > In-Reply-To:
>>> <[EMAIL PROTECTED]
>>> >
>>> > MIME-Version: 1.0
>>> > Content-Type: multipart/mixed;
>>> >        boundary="----=_Part_28704_31437365.1156932401933"
>>> > References: <
>>> > [EMAIL PROTECTED]
>>> ems2.IONAGLOBAL.COM>
>>> >
>>> <[EMAIL PROTECTED]>
>>> >
>>> <[EMAIL PROTECTED]>
>>> >
>>> <[EMAIL PROTECTED]>
>>> >
>>> <[EMAIL PROTECTED]>
>>> >
>>> > ------=_Part_28704_31437365.1156932401933
>>> > Content-Type: multipart/alternative;
>>> >        boundary="----=_Part_28705_19724073.1156932401933"
>>> >
>>> > ------=_Part_28705_19724073.1156932401933
>>> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>> > Content-Transfer-Encoding: 7bit
>>> > Content-Disposition: inline
>>> >
>>> > Could you please review the registry API and SPI?
>>> >
>>> >   ----- Message truncated -----
>>> >
>>> >
>>>
>>>
>>> --
>>>
>>> Yang ZHONG
>>>
>>>
>
>
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--

Yang ZHONG



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to