I do generally agree with your statements.
But in this case, I was trying to understand the RHQ proposal and their reasoning.
One piece of the puzzle is the RHQ plugin legacy and the JON upstream .
The plugin legacy question basically target re-use, whereas the JON upstream aims at
integration at some later point.
[Plugin re-use]
It would be interesting to know about how many plugins we actually speak about.
The smaller the number, the the more reasonable it becomes to simply rewrite them.
[JON Upstream]
This question is a little more complicated. The AS7 console and JON have an overlap in use
cases.
I can see two strategies at this stage: Either we make sure the AS7 console feeds directly
into JON upstream
(i.e. by re-using the plugin container), which is what H. Rupp suggests I think. Or we
remove the overlap in use cases,
but at the same time make sure both management UI's can be used in conjunction. For
instance by providing means to
combine the UI's in a single console. From what I know so far, the later seems to the
best option to me.
Ike
On Jan 11, 2011, at 4:26 PM, David M. Lloyd wrote:
On 01/11/2011 04:00 AM, Heiko Braun wrote:
> I was looking at the proposal my alter ego send to this list a couple
> of weeks ago:
http://www.rhq-project.org/display/RHQ/AS7+console
>
> What I don't understand is, why should there be an interim layer
> between the AS7 management API's (configuration, deployment, etc) and
> the web-UI?
Yeah. I think it's really kind of crazy to focus on the architecture
without having acquired the basic requirements.
Before we go picking technologies, we need to know:
1. What information should be presented? Be specific - at least, more
specific than "everything".
2. How should the information be organized? In domain mode, maybe
multiple tree views (domain->host->server, domain->servergroup->server)
depending on what information you're after; per server, maybe a basic
tree that's similar to the server model layout?
3. How should the interface flow? For example, perhaps I have a fixed
tree view on the left-hand side that I click on to get at other parts of
the system.
4. Performance requirements? We ought to stipulate that on 2 or 3
specific test platforms, the UI takes no more than, say, a second or two
to fully initialize, and that we take measures to keep assets small so
that page load time doesn't become a significantly detrimental factor.
5. How real-time should the interface be? Are UI views updated
dynamically as they change on the server, for example?
Picking tech before all of these questions are answered is putting the
cart before the horse, to say the least. History has shown that
considering requirements as a second step has led to failure far more
often than not. We need to know what exactly we're trying to accomplish.
--
- DML
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev