The PURL creation and editing UI has become both complicated and arcane. We need to separate the UI into several components, and I think that should be done based on use cases.
Some use cases are:
Simple Redirection (most commonly used - keep it simple)
Managerial Use Cases (librarianship, like 303, 307, 404, and 410 return codes)
Proxying Content (Active PURLs, maybe with Partial PURLs)
Executing Web-Accessible Code (Active PURLs, maybe with Partial PURLs)
We also have an opportunity to create custom or simplified Web APIs using PURLs, and may want to develop UI for that (but that can come later).
The PURL creation and editing UI has become both complicated and arcane. We need to separate the UI into several components, and I think that should be done based on use cases.
Some use cases are:
We also have an opportunity to create custom or simplified Web APIs using PURLs, and may want to develop UI for that (but that can come later).
Note, that this is being discussed on the (private) 3RS wiki: https://wiki.3roundstones.com/Products/PURLs/PURL-Use-Cases.docbook?view