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/96caad053c14fc5546e9bc141bc284e6112dd48e/xwiki-platform-core/xwiki-platform-resource/xwiki-platform-resource-default/src/main/java/org/xwiki/resource/temporary/TemporaryResourceReference.java#L33-L33 >>>>>> >>>>>> 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
