Ah, so my measure of the merit of your suggestions includes "how many other users want this/like it etc". I'm happy for you to ignore that and proceed to debate your views but at this point, am not significantly motivated to continue the discussion on that basis. Or put another way I've probably made as many contributions as I'm going to whilst we haven't talked more widely with users.
I certainly think this work would be best done in a separate interface as I'm reasonably sure at this stage that there will be some implementation surprises along the way that probably shouldn't be exposed on the "stable" interfaces we already have. In fact, I'm wondering why you wouldn't just code it up in a branch/scratch for yourself and see what happens..... On 19 January 2011 01:40, James Grahn <jgr...@simulexinc.com> wrote: > One last thing from the original discussion... > > > On 12/22/2010 3:27 PM, Dan Creswell wrote: > >> Maybe the test we should do first is to ask our users what they think >> about >> the APIs, naming and such....maybe you guys already did that and I haven't >> read enough of the archives to know in which case, my bad. >> > > We haven't gotten to the point of surveying users yet; the start of this > discussion was merely my list of suggestions flowing from being a user of > spaces for years. So the first thing to decide is whether or not any of > the suggestions have merit. (Thanks for your contributions toward that > discussion, by the way.) > > It was also immediately suggested that it might be favorable to preserve > the original Javaspace interface and implement whatever changes we decide to > adopt within a new interface (Riverspace?). > > The implementation cost of such a new service would be relatively low, as > it would share most behavior with Javaspace; the primary cost of that > approach would be potential user confusion over similar-but-distinct > services. > > It may be the best way to introduce changes, however: it would be similar > to introducing Javaspace05 alongside Javaspace, though we'd probably not be > extending the interface this time. > > jamesG >
