NIgel,
1000 works fine for me. I'll mark my calendar.
John
On Mon, Sep 5, 2011 at 5:08 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> John,
>
> Thanks. How about 1000 EDT on Tuesday. (1500 BST)?
>
> (If anyone other than John and Reza wants to join just let me know and I'll
> send you the dial-in details)
>
> Nigel
>
>
> On 02/09/2011 23:06, John D. Ament wrote:
>
> Nigel,
>
> I'm available Tuesday. 0900 isn't great, as I am on a call right before it
> and want to give a few extra minutes for it. Would 0930 or 1000 be ok?
>
> John
>
> On Fri, Sep 2, 2011 at 5:34 PM, Reza Rahman <reza_rahman_at_lycos.com> wrote:
>
>> Nigel,
>>
>> I agree a conference call is the way to go. The time works for me, but I
>> am flexible.
>>
>> Cheers,
>> Reza
>>
>>
>>
>> On 9/2/2011 12:04 PM, Nigel Deakin wrote:
>>
>>> John, Reza, All,
>>>
>>> Just to reiterate, I think we're definitely on the right track with the
>>> @Inject (DI) proposal. I think we've got the scope about right in providing
>>> an improved API that could be used by both Java EE and Java SE users. I look
>>> forward to devoting time to reviewing John's Event Messaging proposal but I
>>> think we should focus on @Inject initially and see how much progress we can
>>> make.
>>>
>>> We've only had comments from me and Reza so far. I'd like to move forward
>>> quickly on this, so if others do want to get involved and make comments then
>>> please do so soon. I shall assume that the absense of comments from an EG
>>> member means you don't have any strong views, are happy for others to take
>>> the proposal forward, and won't be making fundamental objections in the
>>> future.
>>>
>>> Reza has reminded us that he did make some suggestions earlier. I think
>>> this is a reference to his email of 21/22 July, in which he made some
>>> suggestions but deliberately avoided giving much detail. One thing I'd like
>>> to understand is what differences, if any, there are between the two
>>> approaches.
>>>
>>> Can I suggest we have a conference call to discuss that and the other
>>> issues raised so far? I'm thinking of John, Reza and me but any EG member is
>>> welcome to join.
>>>
>>> There's a US holiday on Monday. How about Tuesday 6th Sept at 0900 EDT,
>>> 1400 BST? I can make any time that day, so please suggest any other times
>>> (or days) that work.
>>>
>>> Nigel
>>>
>>>
>>>
>>>
>>>
>>> Some of the topics we need to cover are listed below. This isn't intended
>>> to be a complete list but could form an initial agenda for the call.
>>>
>>> Big questions
>>> -------------
>>>
>>> * Will the new API depend on CDI - either CDI 1.0 (JSR 299) or the
>>> prospective CDI 1.1 (JSR 346) - or merely on Atinject (JSR 330)? Is it
>>> necessary to enable the new API to be implemented using using Atinject (but
>>> non-CDI) frameworks such as Guice or Spring?
>>>
>>> * What should the scope of injected JMS objects be? Do we need to
>>> prescribe a new scope not currently offered by CDI (e.g. Reza's "transaction
>>> scope")? If we decide that the CDI scopes are inadequate this may steer us
>>> away from direct dependence on CDI, or perhaps we should seek changes to
>>> CDI.
>>>
>>> Medium questions
>>> ----------------
>>>
>>> * What changes to the basic API are needed to support message injection?
>>> Possibilities include:
>>> - New MessageFactory interface obtained using ServiceLoader mechanism
>>> - New message factory methods on ConnectionFactory
>>> - Keep existing methods on Session but clarify messages may be used in
>>> any session
>>> - Keep existing methods on Session with no need to clarify messages may
>>> be used in any session
>>>
>>> * Do we need @JmsCredentials
>>> - Need at least for SE use only, perhaps
>>> - Perhaps discuss what createConnection(user,password) means in Java EE?
>>>
>>> * New convenience methods for "implicit conversion" between message types
>>> and payload types
>>>
>>> * JmsDestinationLiteral, JmsConnectionLiteral or JmsCredentialsLiteral
>>>
>>> * ConnectionProducer
>>> - why is this needed?
>>>
>>> * Are @JmsConnection, @JmsDestination qualifiers or annotations?
>>>
>>> Small questions
>>> ---------------
>>>
>>> * Do we need a new SessionType enumeration (rather than using
>>> Session.CLIENT_ACKNOWLEDGE etc)
>>>
>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1392 / Virus Database: 1520/3872 - Release Date: 09/02/11
>>>
>>>
>>>
>>
>