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 <vincent(a)massol.net> 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
<vincent(a)massol.net> 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 <thomas.mortagne(a)xwiki.com>
wrote:
>
> On Thu, Apr 14, 2016 at 4:52 PM, Marius Dumitru Florea
> <mariusdumitru.florea(a)xwiki.com> wrote:
>> On Thu, Apr 14, 2016 at 5:43 PM, Vincent Massol <vincent(a)massol.net>
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/96caad053c14fc5546e9bc141bc284…
>>>
>>> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs