River and Backward Compatibility
levmatta <[email protected]>
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
Read Note *. To me, please do things as best as you can, do not worry about backward compability at all. Personally, I am sick of compromises -this community is thin but strong-, we will adapt! Everything you can fix do so, as best as you can. (Deployment is HARD, you know it) After writing the insanity above, and still proud of it, I must come up with a reasonable alternative. If compability is to be broken there are a few choices: do not break it, do it half way, create an adapter layer. Of course I am advocating the adapter layer. This actually means another project (think of the concurrency utils backport project). A Jini system does not care how things are implemented, so provide a Jini-River adapter toolkit. This would be identical to the current Jini toolkit (same classes, same directory layout), but would connect to the River implementation. Migration will be done as one sees fit, but please allow access to the new functionality in this layer. This will invite to the River project. I would go as far as saying that I beleive this is the Jini way of doing thinks (smart proxies RULE!). Hope this is not a complete absurd, Luís Matta (levmatta) * It was very easy to write all of the above since I do not have any production system running on Jini now (although I will have one soon). -------------------------------------------------------------------------- Getting Started: http://www.jini.org/wiki/Category:Getting_Started Community Web Site: http://jini.org jini-users Archive: http://archives.java.sun.com/archives/jini-users.html Unsubscribing: email "signoff JINI-USERS" to [email protected]