Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [rt-pmc] FW: FW: RT whitepaper check in

Scott,

Thanks for the feedback. 

For point #1 if you want to send me some word, I am sure it would be useful.

For point #2, how does your support for the OSGi EE compare to the recently announced Gemini project?  

For point #3, I agree Equinox can be run on a server with no UI.  However, typically when people refer to a Web App they mean applications with render in a browser, hence the focus on RAP.

I agree with point #4 we need to highlight upfront  the component nature of EclipseRT.

-----Original Message-----
From: Scott Lewis [mailto:slewis@xxxxxxxxxxxxx] 
Sent: Sunday, November 29, 2009 1:08 PM
To: ian.skerrett@xxxxxxxxxxx; Runtime Project PMC mailing list
Subject: Re: [rt-pmc] FW: FW: RT whitepaper check in

Hi Ian,

Here are some comments about this white paper.

WRT ECF specifically...first, in the SOA section, you say this about ECF:

"In addition to the Swordfish project, the Eclipse Communications 
Framework (ECF) contains
libraries that provide asynchronous point-to-point and 
publish-and-subscribe messaging.
Along with the Jetty web server, ECF can be used to create light-weight 
SOA or RESTful
end-points and consumers when a more comprehensive SOA framework would 
be overkill.
[tk: is this true about ECF?]"

1) The parenthetical remark at the end about ECF is true...i.e. ECF can 
indeed be used to create light-weight endpoints...BUT I think it's not a 
good characterization of either ECF or Swordfish to present ECF as 
somehow a 'smaller/less comprehensive soa framework than Swordfish'.  In 
general, I would prefer that the presentation of ECF be given without 
any reference to Swordfish, as it not either a part of nor a subset of 
Swordfish.  ECF is a modular set of frameworks to support inter-process 
communication...and it provides a number of options for doing so...e.g. 
APIs for building RESTful remote services, APIs for discovering and 
accessing remote services, APIs for building services based upon 
asynchronous messaging patterns, and other remote services.  If you or 
others want additional prose/detail or explanation for this let me know 
and I will provide it.  Also...given the use-case-driven nature of 
things, ECF can point to a number of use cases...if these are desired 
(e.g. the recent EclipseRT in Austin  or others that I can point to).

2) I also wish to say about 'Enterprise Applications':  although ECF is 
indeed smaller/simpler/lighter-weight than most 'enterprise frameworks', 
we have been/are already implementing the OSGi R4.2 standards that have 
come out of the Enterprise Experts (EE) group (i.e. what was 
RFC119/distributd OSGi and is now called 'remote services' in the OSGI 
4.2 final spec).  So ECF's work on the OSGI 4.2 standards is very 
relevant to enterprise (at least according to the OSGi EE).

A couple more general comments about the document  i.e. not specifically 
about ECF:

3) I find it somewhat strange that under 'Web Applications' that 
Equinox-on-the-web-server is not presented more obviously.  Running 
Equinox on the server (with or without RAP...or in fact with or without 
any user interface), is something many people are already doing...in 
commercial app servers, cloud computing, server-based products, as well 
as internal enterprise applications, etc.  There are many 
servers/services that have little or no UI at all (or have very 
different clients than PCs/web UIs...e.g. toast) that can/could/will 
benefit from EclipseRT-on-web-servers...and for me this doesn't come 
through clearly in this document.

4) Another point is that although Jetty is a fine web server, I think it 
should be made clear that Equinox/OSGi can be used with or without Jetty 
(e.g. http://www.eclipse.org/equinox/server/).  The more general point 
is that *all* of the projects/frameworks within the EclipseRT are 
modular by their being based upon OSGi/Equinox...and are therefore 
usable either together, separately, or perhaps in pieces (e.g. using 
only REST support in ECF or just discovery, or only parts of p2).  
Although this is discussed at in the existing document (i.e. the last 
paragraph), I think the modular structure of the EclipseRT projects 
should be emphasized up front (perhaps with a graphic?), as the 
'take/use only what you need' aspect is very powerful, and, I believe, 
potentially very attractive to application developers of all kinds (i.e. 
web server/web apps, desktop applications, embedded system dev, etc). 

Scott


Ian Skerrett wrote:
> All,
>
> Here is the first draft of a white paper to answer the question "What is EclipseRT".  As previously discussed, we are take a use case approach to organizing the document.   
>
> Please let me know if you have any feedback by next Tuesday, Dec. 1.
>
> Thanks
> Ian
>
>
> -----Original Message-----
> From: Michael Cote [mailto:cote@xxxxxxxxxxx] 
> Sent: Tuesday, November 24, 2009 3:05 PM
> To: ian.skerrett; jeff
> Subject: Re: FW: RT whitepaper check in
>
> Attached is an update, first draft. I'm also going to send a Google
> Docs invite to it for you to in case you'd like to add comments,
> corrections, etc.: hopefully that'll be easier than a Word doc or
> whatever else.
>
> A few editorial notes:
>
> - I'm sure I've missed mention of projects in the different
> categories, or even mis-characterized the ones I've mentioned - please
> point me in the right direction in those cases.
> - I've marked up some questions in square brackets with a "tk" (easily
> searchable) prefix, like, "[tk: is this true?]" that I'd appreciate
> input on.
> - Once we settle on the main content, I'll write in a conclusion and
> (if needed) change around the introduction/overview.
>
> If this content is in the right direction, I'll expect the next steps
> to be incorporating y'all's feedback and then producing a final draft.
> I'll be off for US Thanksgiving the rest of this week, but will have
> time to work on it next week.
>
> Thanks! ;)
>
> On Tue, Nov 24, 2009 at 9:44 AM, Ian Skerrett <ian.skerrett@xxxxxxxxxxx> wrote:
>   
>> I apologize for the delayed response.  I think this draft looks like you are going in the right direction.
>>
>> Jeff let us know if you have any comments.
>>
>> Ian
>>
>>
>> -----Original Message-----
>> From: Michael Cote [mailto:cote@xxxxxxxxxxx]
>> Sent: Friday, November 20, 2009 2:30 PM
>> To: Ian Skerrett
>> Subject: RT whitepaper check in
>>
>> I don't usually pass up such drafty work on a paper, but I wanted to
>> check in with the general direction I've been going with the RT paper.
>> I'm pretty sure the initial drafts of the first 3 scenarios match the
>> idea we were talking about, but I wanted to check.
>>
>> This is "draft zero" version of the paper with some rough notes on the
>> embedded and platform space along with some thoughts of possible
>> general themes to run through the paper. Meaning, don't worry about
>> the exact wording (or cheesy placeholder images ;>) and all that: I'm
>> more trying to nail down the outline and content ideas.
>>
>> I'll be trying to get to a real draft Monday and Tuesday next week, so
>> any high level input you have would be helpful. And, again, I'm mostly
>> looking to check in mid-draft here to make sure its going in the
>> direction y'all want ;)
>>
>> --
>> http://www.PeopleOverProcess.com | +1-512-795-4307 |
>> http://www.twitter.com/cote/
>>
>>     
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc



Back to the top