Where?

...and who else besides DTP does "connections" ?

Where?

...and who else besides DTP does "connections" ?

John Graham 写道: >> Where? >> > > Since Brian Fitz from DTP started that page, I'd contact him on the DTP > newsgroup or dtp-dev(a)eclipse.org and he can provide further meeting info > as necessary. > > >> ...and who else besides DTP does "connections" ? >> > > There's the server connections in WTP, and the DTP/WTP connections don't > know about each other. Likewise, DSDP has connections to "remote > systems," TPTP has connections to debug/monitor targets, the platform > has connections to source control.... > > Ultimately it would be nice if Eclipse had one notion of "connection" > typed based on what the endpoint is. Tools could then use these > connections in interesting ways. > > -- John > A unified connection framework ? but we know that there is ECF now . what's the different between ECF and the "Unified Connection Framework"? > On Thu, 2008-08-21 at 22:54 +0200, Max Rydahl Andersen wrote: > >> On Thu, 21 Aug 2008 22:21:00 +0200, John Graham <jgraham(a)redhat.com&gt; >> wrote: >> >> >>> As anyone who has built using a number of Eclipse projects knows, >>> connectivity is one fragmented bag of breakage. It hurts us indirectly >>> in JBT because of the DTP/WTP fragmentation, and there's more around >>> useful tools elsewhere that are hard to integrate. >>> >>> Anyone interested in this area is encouraged to participate in these >>> E4 >>> discussions. >>> >> Where? >> >> ...and who else besides DTP does "connections" ? >> >> -max >> > > _______________________________________________ > Soa-tools-list mailing list > Soa-tools-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/soa-tools-list >

...and I actually cannot see what usecase there is for making unified connection framework that crosses all those different technologies...what is the point ?

ECF is lowlevel protocol stuff. I wouldn't implement a JDBC connection on it. ...and I actually cannot see what usecase there is for making unified connection framework that crosses all those different technologies...what is the point ? It is completely different user interaction scenarioes... -max > John Graham 写道: >>> Where? >>> >> >> Since Brian Fitz from DTP started that page, I'd contact him on the DTP >> newsgroup or dtp-dev(a)eclipse.org and he can provide further meeting info >> as necessary. >> >> >>> ...and who else besides DTP does "connections" ? >>> >> >> There's the server connections in WTP, and the DTP/WTP connections don't >> know about each other. Likewise, DSDP has connections to "remote >> systems," TPTP has connections to debug/monitor targets, the platform >> has connections to source control.... >> >> Ultimately it would be nice if Eclipse had one notion of "connection" >> typed based on what the endpoint is. Tools could then use these >> connections in interesting ways. >> >> -- John >> > A unified connection framework ? but we know that there is ECF now . > what's the different between ECF and the "Unified Connection Framework"? >> On Thu, 2008-08-21 at 22:54 +0200, Max Rydahl Andersen wrote: >> >>> On Thu, 21 Aug 2008 22:21:00 +0200, John Graham <jgraham(a)redhat.com&gt; >>> wrote: >>> >>> >>>> As anyone who has built using a number of Eclipse projects knows, >>>> connectivity is one fragmented bag of breakage. It hurts us indirectly >>>> in JBT because of the DTP/WTP fragmentation, and there's more around >>>> useful tools elsewhere that are hard to integrate. >>>> >>>> Anyone interested in this area is encouraged to participate in these >>>> E4 >>>> discussions. >>>> >>> Where? >>> >>> ...and who else besides DTP does "connections" ? >>> >>> -max >>> >> >> _______________________________________________ >> Soa-tools-list mailing list >> Soa-tools-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/soa-tools-list >> >

Did you mean "lower level" as in more specific and fine-grained? Or did you actually mean higher level, as in a higher abstraction with a minimal interface that all sorts of different connection types could implement... as basic as connect(), disconnect() ?

Did you mean "lower level" as in more specific and fine-grained? Or did you actually mean higher level, as in a higher abstraction with a minimal interface that all sorts of different connection types could implement... as basic as connect(), disconnect() ?