Hi, My impression was that it was too complicated, from a caller's POV, to manage the module, the document and then a module-based hierarchy when all you want is a temporary resource URL (for which you should not care about all of these things) and which you could easily resolve with some script service. The main thing is that it must resolve in the browser, for a while at least. Uniqueness would also be easily guaranteed IMO, since it would be a single (Java) service that would be in charge of this and that could take care of synchronization or DB access issues. Also, you`ve mentioned creating a file for the temporary resource. I was under the impression that this API would only take care of assigning and making accessible a temporary resource (URL) and it would be the caller's job to actually retrieve its content (since the resource could be stored in a file, in a wiki page, on some separate service maybe, etc.). Perhaps temporary files could be a default provided helper implementation (since it`s pretty common). Anyway, that was just my (non-binding) view on this which, for me, just feels simpler to use. Since you have the actual problem to fix, you probably know better the actual needs from this API than I got to understand from my quick reading. I personally hope we don`t get to proliferate this yet another document reference (escaping) syntax since we already have too many (dots vs slashes, w/o WebHome, etc. and now syntax vs URL) and our users might be already confused enough. Thanks, Eduard On Mon, Apr 18, 2016 at 7:24 PM, Vincent Massol <[email protected]> wrote:
ok I’m going to implement this format, using the URL serializer/resolver that I’ve committed.
Note that the URL format shouldn’t matter that much since it’s an internal format that we can change later on if we want.
Let me know quickly if you don’t agree.
Thanks -Vincent
On 15 Apr 2016, at 09:26, Vincent Massol <[email protected]> wrote:
@Thomas: are you ok with the proposed format:
http://<server>/<context>/tmp/<module id>/<serialized owner document reference>/<module-dependent resource path>
?
Thanks -Vincent
On 14 Apr 2016, at 17:55, Thomas Mortagne <[email protected]> wrote:
On Thu, Apr 14, 2016 at 4:52 PM, Marius Dumitru Florea <[email protected]> wrote:
On Thu, Apr 14, 2016 at 5:43 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
I’m implementing http://jira.xwiki.org/browse/XWIKI-10375 ("Refactor the temporary resource concept inside the Resource module”) and I need to define a URL format for the new “tmp” resource type.
I’m proposing the following:
http://<server>/<context>/tmp/<module id>/<serialized owner document reference>/<module-dependent resource path>
Serialized document reference uses backslash to escape special characters which breaks the URL in Tomcat for security reasons.
Badly configured Tomcat does not like slash but are you sure about backslash ?
This is based on the existing TemporaryResourceReference at:
https://github.com/xwiki/xwiki-platform/blob/96caad053c14fc5546e9bc141bc284e...
For example:
http://
<server>/<context>/tmp/officeviewer/A.B.WebHome/Q29tcGFueSBQcmVzZW50YXRpb24ucHB0/Company+Presentation-slide0.jpg
Note that in this example from the officeviewer macro the
module-dependent
resource path consists in:
- base64(name of office attachment + hashcode(parameters))
See http://jira.xwiki.org/browse/XWIKI-11528 for the rationale behind it. I was trying to avoid backslash (from the serialized attachment reference) in the URL.
- generated image name from PPT
In this case, the implementation would generate the following file:
[TMPDIR]/officeviewer/A/B/WebHome/Q29tcGFueSBQcmVzZW50YXRpb24ucHB0/Company+Presentation-slide0.jpg
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs