You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Anthony Carlucci (Created) (JIRA)" <ji...@apache.org> on 2012/03/07 18:00:58 UTC
[jira] [Created] (RAVE-506) Static Content Fetcher
Static Content Fetcher
----------------------
Key: RAVE-506
URL: https://issues.apache.org/jira/browse/RAVE-506
Project: Rave
Issue Type: New Feature
Reporter: Anthony Carlucci
Assignee: Anthony Carlucci
Priority: Minor
Add the ability to remotely fetch, cache, and render static content within Rave. This feature should be easy to configure, enable, and disable and not be required by the Rave reference implementation to work out of the box.
Use Case Examples:
- a common company header HTML fragment from a server external to the Rave server
- a common external JavaScript fragment that needs to be embedded on a page
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [discuss] separate auxiliary and optional features from 'core'
[Was: [jira] [Resolved] (RAVE-506) Static Content Fetcher]
Posted by "Carlucci, Tony" <ac...@mitre.org>.
I like the idea of a "rave-aux-services" module, and agree that services like the StaticContentFetcherService belong in there rather than the core.
Tony
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Wednesday, March 07, 2012 3:59 PM
>To: rave-dev@incubator.apache.org
>Subject: [discuss] separate auxiliary and optional features from 'core' [Was:
>[jira] [Resolved] (RAVE-506) Static Content Fetcher]
>
>While I can recognize the usage of this service in certain contexts, I'm
>doubtful this service, and in this form, should belong to the 'core' of Rave.
>
>First of all, I think such a service should not standalone, e.g. should be
>fitted in a more overall design for content (and cache) related services.
>
>Of course, currently there isn't yet such a design, which makes it difficult to
>align with something not there yet. I can say though that will change in a few
>days when I'll make a start (here) on such a design for content services.
>
>Just to be clear: I don't mind having such an auxiliary content service being
>provided for Rave, in the meantime, but do think this one is a bit 'thin' on
>generic usability. Which IMO is a concern for some other features as well.
>
>What I'd like to suggest for this or future auxiliary and optional features is
>that these maybe better be provided through a separate and optional
>rave-aux-services module (for lack of a better name: this is just an idea).
>
>WDYT?
>
>
>On 03/07/2012 06:10 PM, Anthony Carlucci (Resolved) (JIRA) wrote:
>>
>> [ https://issues.apache.org/jira/browse/RAVE-
>506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Anthony Carlucci resolved RAVE-506.
>> -----------------------------------
>>
>> Resolution: Fixed
>> Fix Version/s: 0.10-INCUBATING
>>
>>> Static Content Fetcher
>>> ----------------------
>>>
>>> Key: RAVE-506
>>> URL: https://issues.apache.org/jira/browse/RAVE-506
>>> Project: Rave
>>> Issue Type: New Feature
>>> Reporter: Anthony Carlucci
>>> Assignee: Anthony Carlucci
>>> Priority: Minor
>>> Fix For: 0.10-INCUBATING
>>>
>>>
>>> Add the ability to remotely fetch, cache, and render static content within
>Rave. This feature should be easy to configure, enable, and disable and not
>be required by the Rave reference implementation to work out of the box.
>>> Use Case Examples:
>>> - a common company header HTML fragment from a server external to the
>Rave server
>>> - a common external JavaScript fragment that needs to be embedded on a
>page
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
RE: [discuss] separate auxiliary and optional features from 'core'
[Was: [jira] [Resolved] (RAVE-506) Static Content Fetcher]
Posted by "Drozdetski, Stan A." <dr...@mitre.org>.
[Matt wrote]
----
... I think we also need to think about breaking "core" into more modules as well and start thinking about the modules as a way to compose a target application that includes the pieces it needs. For instance, the username& password management infrastructure, while incredibly valuable to some, is something that we have no need for internally and I would like to find a way to split that out into a separate security module.
One caution: we will have to be careful of is an explosion of modules and should logically compose them so that they are easy to understand and work with.
----
I would add that an explosion of modules might be a *very* good thing if:
- an ecosystem exists to promote, share, and co-develop useful modules (while filtering out the useless ones)... think App Store, but without Apple at the cash register ;)
- dependencies between modules can be declared (e.g., I want to use a module that enforces password strength requirements - but it needs the password authentication module in order to operate)
- a workable module format is established in advance (+1 on Matt's point on logical composition)
- the core remains lightweight - which it should, if the "optional" features are separated out
Stan Drozdetski
MITRE
Re: [discuss] separate auxiliary and optional features from 'core'
[Was: [jira] [Resolved] (RAVE-506) Static Content Fetcher]
Posted by marijan milicevic <m....@onehippo.com>.
On 03/07/2012 11:14 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Wednesday, March 07, 2012 3:59 PM
>> To: rave-dev@incubator.apache.org
>> Subject: [discuss] separate auxiliary and optional features from 'core' [Was:
>> [jira] [Resolved] (RAVE-506) Static Content Fetcher]
>>
>> While I can recognize the usage of this service in certain contexts, I'm
>> doubtful this service, and in this form, should belong to the 'core' of Rave.
> +1
+1
note that, by doing this, some changes in maven profiles could be/are
needed. I am thinking of distribution/cargo profiles, where, taking
password services for example, you need extra dependencies being placed
into application server shared classloader folder.
>> First of all, I think such a service should not standalone, e.g. should be
>> fitted in a more overall design for content (and cache) related services.
>>
>> Of course, currently there isn't yet such a design, which makes it difficult to
>> align with something not there yet. I can say though that will change in a few
>> days when I'll make a start (here) on such a design for content services.
>>
>> Just to be clear: I don't mind having such an auxiliary content service being
>> provided for Rave, in the meantime, but do think this one is a bit 'thin' on
>> generic usability. Which IMO is a concern for some other features as well.
>>
>> What I'd like to suggest for this or future auxiliary and optional features is
>> that these maybe better be provided through a separate and optional
>> rave-aux-services module (for lack of a better name: this is just an idea).
> I think an aux module would be good. I think we also need to think about breaking "core" into more modules as well and start thinking about the modules as a way to compose a target application that includes the pieces it needs. For instance, the username& password management infrastructure, while incredibly valuable to some, is something that we have no need for internally and I would like to find a way to split that out into a separate security module.
>
> One caution: we will have to be careful of is an explosion of modules and should logically compose them so that they are easy to understand and work with.
>
> As we start to talk about the architectural pieces Ate proposed earlier, I think we will start to uncover a lot of the pain points that we all have.
>
>> WDYT?
>>
>>
>> On 03/07/2012 06:10 PM, Anthony Carlucci (Resolved) (JIRA) wrote:
>>> [ https://issues.apache.org/jira/browse/RAVE-
>> 506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>> Anthony Carlucci resolved RAVE-506.
>>> -----------------------------------
>>>
>>> Resolution: Fixed
>>> Fix Version/s: 0.10-INCUBATING
>>>
>>>> Static Content Fetcher
>>>> ----------------------
>>>>
>>>> Key: RAVE-506
>>>> URL: https://issues.apache.org/jira/browse/RAVE-506
>>>> Project: Rave
>>>> Issue Type: New Feature
>>>> Reporter: Anthony Carlucci
>>>> Assignee: Anthony Carlucci
>>>> Priority: Minor
>>>> Fix For: 0.10-INCUBATING
>>>>
>>>>
>>>> Add the ability to remotely fetch, cache, and render static content within
>> Rave. This feature should be easy to configure, enable, and disable and not
>> be required by the Rave reference implementation to work out of the box.
>>>> Use Case Examples:
>>>> - a common company header HTML fragment from a server external to the
>> Rave server
>>>> - a common external JavaScript fragment that needs to be embedded on a
>> page
>>> --
>>> This message is automatically generated by JIRA.
>>> If you think it was sent incorrectly, please contact your JIRA administrators:
>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>>
>>>
RE: [discuss] separate auxiliary and optional features from 'core'
[Was: [jira] [Resolved] (RAVE-506) Static Content Fetcher]
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Wednesday, March 07, 2012 3:59 PM
>To: rave-dev@incubator.apache.org
>Subject: [discuss] separate auxiliary and optional features from 'core' [Was:
>[jira] [Resolved] (RAVE-506) Static Content Fetcher]
>
>While I can recognize the usage of this service in certain contexts, I'm
>doubtful this service, and in this form, should belong to the 'core' of Rave.
+1
>
>First of all, I think such a service should not standalone, e.g. should be
>fitted in a more overall design for content (and cache) related services.
>
>Of course, currently there isn't yet such a design, which makes it difficult to
>align with something not there yet. I can say though that will change in a few
>days when I'll make a start (here) on such a design for content services.
>
>Just to be clear: I don't mind having such an auxiliary content service being
>provided for Rave, in the meantime, but do think this one is a bit 'thin' on
>generic usability. Which IMO is a concern for some other features as well.
>
>What I'd like to suggest for this or future auxiliary and optional features is
>that these maybe better be provided through a separate and optional
>rave-aux-services module (for lack of a better name: this is just an idea).
I think an aux module would be good. I think we also need to think about breaking "core" into more modules as well and start thinking about the modules as a way to compose a target application that includes the pieces it needs. For instance, the username & password management infrastructure, while incredibly valuable to some, is something that we have no need for internally and I would like to find a way to split that out into a separate security module.
One caution: we will have to be careful of is an explosion of modules and should logically compose them so that they are easy to understand and work with.
As we start to talk about the architectural pieces Ate proposed earlier, I think we will start to uncover a lot of the pain points that we all have.
>
>WDYT?
>
>
>On 03/07/2012 06:10 PM, Anthony Carlucci (Resolved) (JIRA) wrote:
>>
>> [ https://issues.apache.org/jira/browse/RAVE-
>506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Anthony Carlucci resolved RAVE-506.
>> -----------------------------------
>>
>> Resolution: Fixed
>> Fix Version/s: 0.10-INCUBATING
>>
>>> Static Content Fetcher
>>> ----------------------
>>>
>>> Key: RAVE-506
>>> URL: https://issues.apache.org/jira/browse/RAVE-506
>>> Project: Rave
>>> Issue Type: New Feature
>>> Reporter: Anthony Carlucci
>>> Assignee: Anthony Carlucci
>>> Priority: Minor
>>> Fix For: 0.10-INCUBATING
>>>
>>>
>>> Add the ability to remotely fetch, cache, and render static content within
>Rave. This feature should be easy to configure, enable, and disable and not
>be required by the Rave reference implementation to work out of the box.
>>> Use Case Examples:
>>> - a common company header HTML fragment from a server external to the
>Rave server
>>> - a common external JavaScript fragment that needs to be embedded on a
>page
>>
>> --
>> This message is automatically generated by JIRA.
>> If you think it was sent incorrectly, please contact your JIRA administrators:
>https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>
>>
[discuss] separate auxiliary and optional features from 'core' [Was:
[jira] [Resolved] (RAVE-506) Static Content Fetcher]
Posted by Ate Douma <at...@douma.nu>.
While I can recognize the usage of this service in certain contexts, I'm
doubtful this service, and in this form, should belong to the 'core' of Rave.
First of all, I think such a service should not standalone, e.g. should be
fitted in a more overall design for content (and cache) related services.
Of course, currently there isn't yet such a design, which makes it difficult to
align with something not there yet. I can say though that will change in a few
days when I'll make a start (here) on such a design for content services.
Just to be clear: I don't mind having such an auxiliary content service being
provided for Rave, in the meantime, but do think this one is a bit 'thin' on
generic usability. Which IMO is a concern for some other features as well.
What I'd like to suggest for this or future auxiliary and optional features is
that these maybe better be provided through a separate and optional
rave-aux-services module (for lack of a better name: this is just an idea).
WDYT?
On 03/07/2012 06:10 PM, Anthony Carlucci (Resolved) (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/RAVE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Anthony Carlucci resolved RAVE-506.
> -----------------------------------
>
> Resolution: Fixed
> Fix Version/s: 0.10-INCUBATING
>
>> Static Content Fetcher
>> ----------------------
>>
>> Key: RAVE-506
>> URL: https://issues.apache.org/jira/browse/RAVE-506
>> Project: Rave
>> Issue Type: New Feature
>> Reporter: Anthony Carlucci
>> Assignee: Anthony Carlucci
>> Priority: Minor
>> Fix For: 0.10-INCUBATING
>>
>>
>> Add the ability to remotely fetch, cache, and render static content within Rave. This feature should be easy to configure, enable, and disable and not be required by the Rave reference implementation to work out of the box.
>> Use Case Examples:
>> - a common company header HTML fragment from a server external to the Rave server
>> - a common external JavaScript fragment that needs to be embedded on a page
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
[jira] [Resolved] (RAVE-506) Static Content Fetcher
Posted by "Anthony Carlucci (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RAVE-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anthony Carlucci resolved RAVE-506.
-----------------------------------
Resolution: Fixed
Fix Version/s: 0.10-INCUBATING
> Static Content Fetcher
> ----------------------
>
> Key: RAVE-506
> URL: https://issues.apache.org/jira/browse/RAVE-506
> Project: Rave
> Issue Type: New Feature
> Reporter: Anthony Carlucci
> Assignee: Anthony Carlucci
> Priority: Minor
> Fix For: 0.10-INCUBATING
>
>
> Add the ability to remotely fetch, cache, and render static content within Rave. This feature should be easy to configure, enable, and disable and not be required by the Rave reference implementation to work out of the box.
> Use Case Examples:
> - a common company header HTML fragment from a server external to the Rave server
> - a common external JavaScript fragment that needs to be embedded on a page
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira