On 03/07/2012 11:14 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: Ate Douma [mailto:[email protected]]
Sent: Wednesday, March 07, 2012 3:59 PM
To: [email protected]
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
