On Thu, 28 Dec 2000, Bordet, Simone wrote:
> For a client is easier to subscribe to a specific topic, instead of
> searching somewhere for the right selector, isn't it ?
That depends on whether the client/users model is exactly the same as
ours, that is, if the separation of topics we create is exactly
what he is looking for.
With several topics we "hard code" the information channels from the
server, with one topic channel we leave it to the client to modify the
information channel to their specific needs. For me the latter approach
seems more flexible, as it is easier to combine the information from
several parts of the server based on a single selector instead of creating
several selectors for several topics. For an example, think of a situation
where you want to monitor the server usage based on a login ID.
> I have in mind a JBossJMSMonitoring interface with only public final static
> in it, so that the client can know which properties we set in messages, what
> do you think ? (lots of constants, anyway, and difficult to mantain...)
Yes that's a good idea. Although I think the name of the interface could
be simpler :) Maybe just org.jboss.monitor.MonitorConstants or
MonitorProperties.
> Better yet, collect in the admin GUI all properties of all messages and give
> clients a GUI way to select only specific properties, and so filter
> messages; but from API point of view ?
Yes, selecting the messages based on properties is a feature that advanced
admin tools should provide. Also being able to query these properties from
the server is required for a generic J2EE server admin tool --> which
means we would need an API (not just model) --> JSR77's domain.
-- Juha
