[sip-comm-dev] Resource sharing service + internationalization


Hello everyone,

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

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.

I agree on this one. A service that is dedicated to
sharing resources should be considered only after we
actually need.

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

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?

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
just build-and-run.




To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net