From: Adam R. <ad...@ex...> - 2011-06-13 15:23:33
|
>> Its not that I am being unhelpful here, its that we have different >> perspectives and responsibilities. My perspective is that I am not >> concerned with backwards compatibility in the XML-RPC API and believe >> that that will be fine for the majority of users. Your perspective is >> that of a user that would prefer to see XML-RPC backward compatibility >> because its difficult inside your project. > > Yup...that sums it up pretty well. > >> Also we are both quite busy people, so I tend to focus on what is >> important to me. Maintaing backwards compatibility in the XML-RPC API >> is not important to me personally, I am not personally interested in >> it and no one is paying me to do that. Conversely, I am sure you focus >> on what is important to you... So if this is very important to you, >> then I also know that you have the necessary programming skills to >> look into this yourself and propose or contribute a fix (if one is >> possible). > > I would love to....but in this particular case, the new Unix permissions stuff touched nearly a > hundred source files. As you point out, there's not enough time for me to try and understand all > the intricacies of that code at this time, due to it's breadth and impact on the main code base. Yes, there were a LOT of changes involved, but you should only have to focus on the classes in org.exist.xmlrpc and org.exist.xmldb - maybe 4 files in total I think. > What spare time I have, I'm going to try and devote this week to delving into the "duplicate > attribute" bug, since that has been tough to replicate with a simple test case, so I'll have to dive > into the code to figure out what is causing this. This bug has serious implications on data and > code integrity, even though it's obviously a very specific set of circumstances (as yet unknown) > that cause it to manifest. Plus fixing that bug means I can probably update our remote instances to > the latest SVN version which would resolve the XML-RPC API issue. Okay cool, it would be great to get a reproducible test case for that one. > Because of instabilities, security re-architecture (and bugs), database structure/version changes > and the like, we've been unable to upgrade since last July, which is almost a year ago now. Yes trunk has seen a lot of churn in the last year. Growing pains ;-) However, it is trunk which is stable for developers, but we dont guarantee stable for production. 1.4 is our production version and 1.4.1 is on the doorstep of being released, a new preview of 1.4.1 is out and in a few weeks if we dont have any reported issues then it will hit the streets. I would expect shortly after 1.4.1 to see a release of 1.6 our new Next Gen version based on 1.5 dev code. > The instability of the code base and lack of a 1.5 production capable release has been a concern to > me for some time now, since in the past everything was pretty much rock solid. Massive changes that > touch the whole code base, such as the recent permissions stuff, worry me since there's a good > chance that they will take a while to stabilize/debug (not to mention the testing required and > potential impact on existing applications, which I suspect will be great) and thus the code base > continues to be unstable. Actually the ACL changes were relatively straight forward and apart from all the glue that had to be modified the core changes are minimal and if you choose not to use the ACL stuff, but stick with the default Unix Style permissions then you should not experience any differences in the core. > The only reason I had updated our R&D instances to the latest SVN revisions was to be able to test > the impact of the permissions stuff on our apps. I've reverted to a revision just prior to the > permissions stuff to get our deployment stuff to work again, since that was the easiest path for us. > I'll look into managing multiple versions of the eXist code base when we're ready to test the > permissions stuff. Given how extensive our app is and our history of finding issues in new code as a > result, I suspect that we'll chat again soon. ;-) Having testers like yourselves is incredibly valuable to us, and we appreciate the feedback you provide, but I am sure you can imagine, that without reproducible test cases life can be very hard for us. >> Dont get me wrong, I would love to have the resources to take every >> sensible suggestion on-board and spend time working on everything for >> free for everyone, but I just dont have the resources at my disposal. > > Same for me....though I think some time will free up soon for me to do more work on the eXist code > base, which I have not been able to do for the past few months. > > -- > Andrzej Taramina > Chaeron Corporation: Enterprise System Solutions > http://www.chaeron.com > -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |