Re: [stp-dev] transcript of IRC 8 March 06

[David.Brandow@xxxxxxxxxx]

I apologize for not attending these
IRC sessions, technical difficulties.  But I did want to voice an
opinion about the WSDL EMF model, I agree with the notion that it would
be too restrictive to simply adopt the WSDL EMF model, we need to make
allowances for multiple, and potentially new, versions of WSDL and other
contract languages as well.  I would think we would want to keep the
base model of a contract language as simple as possible, make it extensible
and then provide exemplars for WSDL, since thats obviously the first-class
citizen.

-----------------------------------------------
Keep your stick on the ice,

David Brandow
Sybase EAServer Engineering

Oisin Hurley <ohurley@xxxxxxxx>
Sent by: stp-dev-bounces@xxxxxxxxxxx

03/08/2006 02:34 PM

Please respond to
STP Dev list <stp-dev@xxxxxxxxxxx>

To	STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject	[stp-dev] transcript of IRC  8 March 06

dparikh joined the chat room.
[16:44] DavidBosschaert left the chat room. ("Trillian (http:// 
www.ceruleanstudios.com")
[16:44] DavidBosschaert joined the chat room.
[16:58] boisvert joined the chat room.
[17:02] sdaume joined the chat room.
[17:03] AMiguel joined the chat room.
[17:03] oisin: hi all
[17:03] boisvert: howdy!
[17:03] sdaume: hi guys
[17:04] AMiguel: hi
[17:05] sdaume: Oisin, as a first agenda item I would like to ask you  
to clarify some of the PMC changes
[17:06] oisin: ok - it's a little confusing!
[17:06] sdaume: maybe I will just put forward a few specific questions
[17:06] oisin: currently on the PMC are:  Oisin Hurley, Alain Boulze,
 
Karl Reti, Carl Trieloff
[17:07] sdaume: Ok, I got the impression Carl is not on the PMC anymore
[17:07] sdaume: ?
[17:08] oisin: there are a couple of issues
[17:08] sdaume: fire away
[17:08] oisin: 1. to be not on the PMC Carl will need to formally resign
[17:10] oisin: 2. afaik he has done that, but for the moment he stays  
on because EclipseCon has taken up the time of the EMO and staff
[17:11] oisin: 3. I need to meet with Bjorn, the process director, at  
EclipseCon and do a formal introduction
[17:11] sdaume: so who is PMC lead now ?
[17:11] oisin: that's my role
[17:11] sdaume: ok
[17:12] oisin: I will take an action item to get an accurate  
statement out to the list
[17:13] sdaume: if possible, could you tell us how those changes came  
about ? I didn't see anything about this on the PMC mailing list
[17:14] oisin: (just checking my mail)
[17:15] oisin: yes you are correct, there was no discussion on the  
mailing list
[17:16] oisin: instead the mailing went directly to the PMC  
individuals and Bjorn
[17:17] oisin: are you on the list stefan?
[17:17] sdaume: I am
[17:20] oisin: the reason I ask is that Bjorn had to do some  
maintenance work on it recently -- just checking that no-one got  
accidentally bumped from it
[17:20] oisin: stefan, did you receive the emails regarding call  
scheduling etc today?
[17:21] sdaume: i did
[17:24] oisin: I will send my contact details to the list -- feel  
free to give me a call at any point (GMT
[17:25] oisin: any other q's?
[17:27] oisin: I've a couple of things (1) the Corona project, (2)  
the service creation subproject 'architecture' sent to stp-dev
[17:27] boisvert: can somebody introduce the Corona project, i'm not  
familiar with it
[17:28] oisin: http://www.eclipse.org/proposals/corona/
[17:28] oisin: it bills itself as the 'Tools Services Framework'
[17:28] oisin: I was on the creation review today
[17:29] oisin: At this point in time I readily admit I don't  
understand half of it.
[17:29] oisin: However, they see some overlap with STP
[17:29] oisin: The one thing that I took from the creation review is  
that they are basically exposing eclipse extension points as web  
services
[17:30] oisin: I think that the tie-in to our tooling is probably at  
the point of importing the interface offered by an extension point to  
make a contract and then perhaps doing a 'deployment' into the eclips\
e install
[17:31] oisin: They have been encouraged to have a BOF-style thing at  
eclipsecon, which might be fun to attend - especially since there was  
hints of mexican beer being supplied
[17:33] boisvert: ok, thanks
[17:33] oisin: Did any of you guys get a chance to check out the SC  
skeleton I sent to the dev list?
[17:34] oisin: Please don't be shy about feedback
[17:34] oisin:
[17:34] boisvert: so my question would be how would we go about  
working with the corona project?
[17:34] boisvert: are you suggesting that eclipsecon would be the  
venue for some kind of kickoff discussion?
[17:35] oisin: I think it would be good to get a bit of context with  
them before then.
[17:36] oisin: I would suggest that we have an IRC meet or a concall  
this week or early next week
[17:36] oisin: then we would be in a better position to talk details  
at eclipsecon
[17:37] oisin: what do you think?
[17:37] boisvert: yes, i sure would be interested in better  
understanding their intents
[17:37] sdaume: that would good. i suggest early next week
[17:38] boisvert: maybe we could substitute next week's STP IRC chat  
with a chat w/ corrona
[17:38] oisin: what about mon/tues?
[17:38] oisin: [for selfish reasons - I'm not available wed/thu/fri]
[17:39] sdaume: monday
[17:40] oisin: gimme the plus ones minus ones guys
[17:40] oisin: +1
[17:40] DavidBosschaert: Either Monday/Tuesday is fine +1
[17:40] boisvert: monday/tuesday +1
[17:40] oisin: ok I will get in touch with the lead and propose we  
have a session on this channel.
[17:41] boisvert: wonderful
[17:41] sdaume: maybe a conf call would be better for this ?
[17:42] oisin: I'm open to either approach - we can provide the bridge
[17:42] boisvert: i'm open to both as well
[17:42] oisin: right we'll see what the corona chaps can do, leave it  
with me.
[17:42] sdaume: I guess an introduction and overview of the Corona  
project is easier delivered in a conf call
[17:43] oisin: it's the question throughtput that is the key part
[17:44] oisin: ok - have we got anything else to bring up?
[17:44] dparikh: I have a question about SC skeleton.
[17:44] dparikh: Is it possible to use WSDL as contract model ?
[17:44] oisin: ask away - can you introduce yourself too, please, I  
don't recognise the nick!
[17:45] oisin: I think using WSDL as the contract model is one  
perfectly acceptable approach
[17:45] dparikh: sure I am Devang Parikh. I work with Dan Berg on STP  
Core Framework
[17:45] oisin: Hi Devang!
[17:45] dparikh: hey
[17:46] dparikh: Since many implementation uses WSDL to describe  
their interface or have clear mapping to WSDL,
[17:46] dparikh: they will not have to create mapping to another  
contract model.
[17:46] boisvert: one of the challenge these days is to model  
'listener' type interactions through WSDL
[17:47] dparikh: last I check WTP had EMF model for WSDL.
[17:47] boisvert: not that you can't model these interactions, but  
mostly that almost no tools seem to support the necessary MEPs and  
they fall out of the interop standards
[17:47] oisin: I think that a key requirement of the contract model  
is that it can produce WSDL - whether or not the in-memory model is  
WSDL is not that important
[17:48] boisvert: ok, that i can see working in the not too distant  
future
[17:48] sdaume: oisin are you proposing to create an EMF-based  
contract model from scratch
[17:49] sdaume: that will have mappings to specific contract  
languages like WSDL
[17:49] oisin: I'm personally inclined an EMF model, purely because  
we can get some freebies in terms of generating the basis for the  
notification etc
[17:50] dparikh: I agree that we should use EMF model. My question is  
can we use WSDL EMF model from WTP ?
[17:51] sdaume: so the WSDL EMF model is the contract model ?
[17:51] dparikh: yes that is what i am thinking.
[17:51] sdaume: I think this is to restrictive
[17:51] oisin: Is the WSDL EMF model purposed just to WSDL?
[17:52] oisin: I'm with stefan on this -- I think we should put in  
place something that doesn't attempt to meta-model world+dog but will  
give us something from which we can easily address a wsdl requirement.
[17:53] sdaume: question is will we have a meta-model to build on or  
do we have to define this from scratch
[17:54] boisvert: i would also hope we can reuse the WSDL EMF model  
for something like this
[17:54] oisin: we should certainly do a real review of the WSDL EMF  
model and see what is missing in our opinions
[17:54] oisin: we should also be informed by other contract languages  
that we know
[17:55] dparikh: yes that will be good to see what we will have to  
add/enhance on WSDL model
[17:55] dparikh: *WSDL EMF model
[17:56] oisin: from my perspective there are two primary requirements  
of the model -- it must be transformable to WSDL (1.1 and 2.0) and it  
must be extensible
[17:57] boisvert: Guys, I just noticed Karl Reti's EclipseCon  
presentation on the STP project at http://eclipsezilla.eclipsecon.org/
eclipsezilla/php/attachment.php?bugid=235
[17:58] boisvert: when we are done discussing the SC skeleton, i'd  
like to ask a few questions
[17:59] oisin: can we take the skel discussion to the list? I suggest  
that we all pile in and list our requirements of the contract model.  
I know for a fact that the gentlemen from sybase, who are not on this\
discussion, have some prior in this area.
[18:00] dparikh: yep. let's discuss this on list
[18:00] oisin: any objections?
[18:01] oisin: not seeing any: alex do you want to go with the  
questions?
[18:01] boisvert: not at all, i don't feel like i know enough about  
the WSDL EMF model now to make good judment
[18:01] oisin: I mean the questions you had for after the SC skel  
discussion
[18:01] boisvert: ok, so about Karl's presentation, i see the slide  
about "Alignment with SCA"
[18:01] oisin: slide number/
[18:01] oisin: ?
[18:02] oisin: 15
[18:02] boisvert: yes
[18:02] boisvert: slide 15
[18:02] oisin: ok go for it
[18:03] boisvert: and i'm wondering how that relates/impacts similar  
model like JBI for deployment, etc
[18:03] boisvert: my most important concern being that I don't see  
JBI mentioned explicitly anywhere else
[18:04] oisin: this was a big discussion item at the F2F -- there was  
a not heated but slightly warm exchange
[18:04] dparikh left the chat room. ("Chatzilla 0.9.72 [Firefox  
1.0.7/20050915]")
[18:04] AMiguel left the chat room. ("Chatzilla 0.9.70 [Firefox  
1.5.0.1/2006011112]")
[18:05] oisin: the logicblaze guys are JBI all the way and were not  
too keen on an SCA based thing
[18:05] boisvert: understood
[18:06] boisvert: so there is interest in JBI support as well?
[18:06] oisin: they were assured that the SCA Assembly model is  
transformable to JBI
[18:06] boisvert: ok, that's good to know
[18:06] oisin: There was a whiteboard discussion between the aligned  
parties IBM/BEA and ObjectWeb/LogicBlaze
[18:07] oisin: JBI is not out of scope
[18:07] boisvert: i'll take this as assumption right now
[18:07] sdaume: I think it was agreed that extension points needed to  
be defined for that ?
[18:07] oisin: stefan is correct
[18:07] oisin: the nature of the solution however is not clear
[18:07] oisin: at this point in time
[18:07] boisvert: right, ok, so health discussion around supporting both
[18:08] boisvert: (healthy)
[18:08] oisin: oh yes.
[18:08] boisvert: that's good to hear
[18:08] oisin: I suggest, alex, that you might send a mail to this  
effect to the list to see who the interested
[18:08] boisvert: that's all the question i have about the  
presentation right now
[18:08] oisin: parties are...
[18:08] boisvert: sure
[18:08] oisin: we need to get discussion going on that topic too.
[18:09] oisin: ok. we're a little over time, is there anything else  
we got to talk about?
[18:09] sdaume: particularly with the changes in SCA
[18:09] oisin: tracking SCA is something that we will be actively doing.
[18:10] boisvert: nothing on my side
[18:10] DavidBosschaert left the chat room.
[18:10] oisin: ok let's call it day so
[18:11] boisvert: alright, thanks guys
[18:11] oisin: thanks
[18:11] sdaume: bye

_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev