For this service I was thinking more as a way to access the file
system - that is create/read/write/delete temporary or persistent
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) service addressing
the issue with the resources - ResourceSharingService, or
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.
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. WDYT?
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 CallHistoryService
and MessageHistoryService to log call events and chat
Any comments on the design, the quality, the naming..
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 implementations of 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?