>>> 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. Ok.
>>> 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. HexUtils is a generic class to transform data from/to HEX format, so I'd put in the same package of MD5 ... Bye
