On 02/24/2016 10:37 PM, Angel Ezquerra wrote:
The existing FID is defined in https://kallithea-scm.org/repos/kallithea/files/05a85a6cecba5c8caeb7996590365d5d9bc523c9/kallithea/lib/helpers.py#L123 . It is not perfect but seems to me like it is significantly simpler than the alternative proposal. Especially because including "python urllib" in the specification sounds inconvenient for implementation in other languages and probably not is a place where Python guarantee 100% stability - especially not as various vulnerabilities are discovered.It _could_ perhaps make sense to define a special format for "I don't care about revision" links ... but why not just set it to "" like for PRs and get ids like "C--067e5b4403fb". So the current Python reference implementation for PR ids is: "C--" + hashlib.md5(u'kallithea/templates/changelog/changelog_summary_data.html'.encode('utf8')).hexdigest()[:12] - that must be easy to add to TortoiseHg. Or using my favourite scripting language: printf kallithea/templates/changelog/changelog_summary_data.html | md5sum |sed -ne 's,^\(.\{12\}\).*,C--\1,p' Can it be much simpler? (I guess one reason '.' generally should be avoided in ids is that it would be inconvenient when referencing it from css.)The ideal solution to the problem I'm trying to solve would have 4 features: 1. A way to generate unique links to navigate directly to any file diff within a changeset review page 2. Be simple 3. Be highly discoverable / guessable 4. Be stable 5. Generate legal HTML My proposal covers #1, does OK (but not pefect by any means) with #2 and #3 and fails (slightly) #4 and #5.
2: Considering the amount of code that is being called in the proposed scheme, I don't think it is simple. Can you make a full specification that can be implemented in some other programming language?
3: The proposed scheme is "approximately readable" but generally not writable - and the details are not at all discoverable/guessable. And for 100 characters long file names with odd characters, it is hard to read / compare targets.
Your proposal covers well #1,#2, #4 and #5 but does poorly at #3.
3: I would claim that someone who seriously wants to reverse engineer the scheme, sooner would get a fully correct implementation of the existing scheme than of the proposed one. Even more so if we document what the scheme is.
I'd rather get your proposal in than nothing,
Byt "my proposal" is already in? What more is needed?
but I worry that "non-insiders" will never be able to use the feature. How could they guess the steps they should follow to generate the required HTML address?
They would guess it the same way as guessing that they have to use the Python library and apply some specific tweaks: Don't guess it! Search and find the answer. In the source, in google finding this discussion, in documentation ... or by asking.
An ideal solution would be to be able to do something akin to what you can do to access the raw-files in the regular mercurial server (and Kallithea too, I think). With the regular server you can just append a 'raw-file' plus the file path to the changeset revision to get the corresponding version of a the file on that changeset. It would be neat to be able to do that somehow, and thus completely avoid the need to encode the file path (beyond what urllib.pathname2url does, I guess). Do you think there is some way to do that?
You can perhaps make the controller read the URL and put something into the page that make javascript navigate to that point ... or make javascript compute the target based on the URL.
/Mads _______________________________________________ kallithea-general mailing list [email protected] http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
