Tom Hobbs wrote:
>From what I understood, you wanted to write a Secure End Point
implementation which would have a fixed dependency on OSGi sources. I have
a read a lot of articles about people complaining about all sorts of things
(from Scala, Clojure to Ruby/Rails) and how they "just wanted to do this"
but they ended up having to download dependency after dependency. It was my
concern that people wanting to use River would somehow be forced to download
OSGi also, even if they didn't want those bits of functionality.
Yes my implementation would depend on OSGi, is that bad?
That particular implementation depending on it, no. But River depending on
it, yes. Isn't it?
Don't know, I just don't have the experience to comment on that, the
functionality I need is in this jar.
bash-3.00$ ls -lah bin
total 788
drwxr-xr-x 2 peter staff 512 Oct 12 08:00 .
drwxr-xr-x 6 peter staff 512 Oct 12 08:19 ..
-rw-r--r-- 1 peter staff 378K Oct 12 08:17 felix.jar
I can create an implementation that concentrates on the connection alone
for the main trunk, leaving security up to the implementer as you have
suggested.
It does take up considerable time to continue discussing the OSGi issue
and it probably isn't right to force it on everyone, unfortunately I
haven't been able to find the features I need elsewhere and believe me,
I have been looking.
With that in mind, I would like to create an Internet version of River
on svn, utilising the security, ClassLoader visibility and versioning
features of OSGi, but keep it out of the main trunk, so that I can work
on it without causing concern for others. This will free up some more
time for me to code the implementation and experiment, then if at some
later date it proves worthwhile it may be merged with the main trunk.
