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

yes, what is the ultimate scope and planned for size of this
whitepaper?  there are significant things we can speak to on the jetty
front and it is quite under represented in this context but if the
ultimate goal of the paper is a brief 5 page general intro to runtime
as a platform then sprucing up that section is a lot more streamlined
then knocking out feature lists and capabilities, etc..

jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Mon, Nov 30, 2009 at 08:43, Douglas Clarke <DOUGLAS.CLARKE@xxxxxxxxxx> wrote:
> Ian,
>
> I have done a brief read of the paper and will get you feedback as I find the EclipseLink content missing for the most part. We need to add in some context on where EclipseLink can be used with some contextual use cases. I believe for some technologies such as ECF, EclipseLink, Rienna where we offer application infrastructure that can be used in RCP, Web, EE we should factor out a common runtime infrastructure section that highlights these features as usable across any of the architectures.
>
> I am flying today and will try to pull together some notes for you.
>
> Doug
>
> -----Original Message-----
> From: Ian Skerrett [mailto:ian.skerrett@xxxxxxxxxxx]
> Sent: November 30, 2009 9:30 AM
> To: Scott Lewis; Runtime Project PMC mailing list
> Subject: 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
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>


Back to the top