I don't think we need "Provider" at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
