Hi Edy,
On 19 Apr 2016, at 03:54, Eduard Moraru <[email protected]> wrote:
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.
What you proposed would have exactly the same complexity from a caller’s POV (this is what I tried to explain in my previous reply): The caller will always need to pass all the various parts making up the URL. The reason is simple: the caller must have the **same** URL generated for the same resource. So you need to pass those. In your case you’d just have needed to save them all in the DB...
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).
What I’m doing is: * The generation of the temporary URL through a “tmp” URL serializer (that’s the caller’s side). The caller will get a File (or a Path if we use NIO). ATM it’s up to the caller to save that file though (verify first if it exists or not). It’s easy to add a script service for that if we want although it’s a one-two liner to save it once you get the File or Path handle. * The handling of a “tmp”-type URL through a ResourceReferenceHandler and the serving of its content.
Anyway, that was just my (non-binding) view on this which, for me, just feels simpler to use.
IMO it brings complexity in the implementation: * Non-legible URLs * DB table (with lots of columns to be able to match a given resource and its parameters with a unique id) * Maintenance: you store temporary data in the DB so when you make a backup and want to transfer that to another instance you need to empty the table. * Harder to debug (see previous mail) From a User POV (I assume you mean caller POV) as I mentioned above it’s exactly the same :) From a real User POV, it’s transparent since these URLs are internal URLs, not meant to be exposed/bookmarked/etc.
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.
The goal is to use the new URL serializer/resolver in URL path segments where we serialize entity references (ATM the only places are the tmp URL and the “reference” URL scheme). In any case we can change the URL format any time in the future. Thanks -Vincent
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