Emil Ivov wrote:
For this service I was thinking more as a way to
access the file
system - that is create/read/write/delete temporary
files. I think that resources are a little bit out
of the scope of this
OK I see what you mean and I agree.
I agree that there should be a (maybe a dedicated)
the issue with the resources -
ResourceService, or ResourceManagementService..
24 hours after my original post I am beginning to
actually doubt that
:). In 90% of the cases a bundle would come with
its own resources
(icons, bitmaps or whatever ) and would be the only
one using it. In
order to get them through a ResourceService it would
first have to
register them ther and to do so it would have to
access them ... So I
wonder what good it would do.
There is, however, the case of a bundle that would
need to export
resources in order to make them accessible for
others so the
ResourceSharingService you mention is a good idea.
We'd need some
concrete use cases before (and if) we decide to go
further with this one.
I agree on this one. A service that is dedicated to
sharing resources should be considered only after we
On the internationalization - I think that
generally each bundle
should handle his own strings.
One can think of an improvement -
maybe an addition to the Resource*Service which
could provide internationalization for some "popular"
texts, like "Hello World",
"Two beers or not two beers", etc..
I was thinking about something that's more of a
Locale manager. A bundle
may come in with its own sets of strings but it
would need a centralized
way of determining which one to use. Yet maybe the
simplest way to deal
with that would be to do it the standard Java way.
I've never really
used it so I really have no idea how well it would
fit our environment.
I totally agree with you - it would be best to Keep It
Simple and follow the Java way - use ResrouceBundle-s.
To synchronize the Locales (even if the user changes
it during the execution of the program) we can simply
make it a propery handled by the ConfigurationService.
By using this service everyone who is concerned can
subscribe and receive events if the Locale changes. An
additional advantage is that the Locale will be
automatically saved to the configuration file and on
restart it will keep the user selection (I would HATE
a program that keeps forgetting my language
I've written a small document describing the
functionality of the HistoryService along with a
simple example. It is not directly linked with the
protocols but will be used from the
and MessageHistoryService to log call events and
Any comments on the design, the quality, the
on everything are highly appreciated
I really like the way you've done it. I find the
documentation a bit too
abstract though. It would be great to add a few use
case examples. I
know that you are using the history service in the
the call and message history services. Maybe you
could add a paragraph
or two explaining how you do it. Is that making any
sense to you?
Yes, after the other two services that use the
HistoryService are completely finished I will write
dedicated documentation for them (because generally
the developer would access CallHistoryService and in
rare cases the HistoryService itself). I will also add
some cross-references, so that the whole picture can
become more clear. Also I plan extending the example
so that it becomes a whole bundle which everyone can