>> 1) I don't think we should deprecate methods that we've never released. >> IMO, deprecation is for backward compatibility for perhaps one release cycle >> to allow developers who've used a method to transition to the newer API. >> I'd say let's remove the methods instead of deprecating them. If we need >> them later, they're in SVN and can be easily restored. >Right, but if there aren't objections I'd prefer to keep them at the >moment (so i can not add the deprecation on them), and maybe add the >new version (by mixing two methods, to return a String).
I agree that we should not be tagging any new methods as deprecated. This is only likely to cause confusion. >> 2) I think MD5 should go in core/util -- there's nothing specifically "web" >> about it. >My initial version of it (and the HexUtils) was in core, but to avoid >fill with strange code I moved them to web, but I agree with you, so >if there aren't objections I can move them (MD5 and HexUtils) in core, >under the org.apache.pivot.util package. I haven't looked at these files closely yet, but I am guessing that org.apache.pivot.util is a good place for MD5, whereas HexUtils may be better off as a package private class in org.apache.pivot.web or as an inner class of DigestAuthentication. G
