| [p2-dev] Repository download addressing questions |
| Hi, I am working on improving error handling and robustness in the Repository Transports. I have a question regarding addressing when doing a download. I have two questions: (1) Is it reasonable to enforce that everything to download from repositories is adressed by URI ? The Transport.download() method has a String argument for "toDownload". Why is this not a URI? (I know that ECF supports different addressing schemes - i.e. that you could plug in a "fruit" protocol to handle addresses like "fruit=>banana", but is this really supported higher up in the p2 stack? The reason for asking is that there are assumptions in the lower level code that the "toDownload" has certain characteristics. The various places in code that deals with this string has quite simplistic parsing and many things supported by a URI are simply ignored, and this leads to "mysterious exceptions" as one problem is mistaken for another. It also blocks use of certain types of addressing. (2) What is the correct scope for remembering username/passwords? The current implementation performs the following: IPath hostLocation = new Path(xmlLocation).removeLastSegments(1); It then uses the "hostLocation" as the key for storing username/password for later use. What is the intention here? This implementation would have different username/password settings per directory on the remote side. Potentially driving a user nuts if the repository is organized in multiple directories. When looking up a stored password is seems more reasonable to search towards the root - eventually getting the information for the true host. When password fails however, some support is needed from the UI to allow the user to enter username/password for a root address. Say that a download is performed from http://somwhere.com/a/b/c/d.jar and there is no username/password found in the secure store. When the user is prompted, the user could simply be given opportunity to shorten the address to http://somewhere.com to make it valid for all paths at that location. This is also affected by use of non URI. The construction of the hostLocation using Path will simply not produce good hostLocation keys for all URIs. |