On Mon, Nov 16, 2015 at 5:03 PM, [email protected] <[email protected]> wrote:
> Hi Edy, > > On 16 Nov 2015 at 15:56:09, Eduard Moraru ([email protected](mailto: > [email protected])) wrote: > > > Just a note (not saying we should not do it) about dumping serialized > > attachment references straight to the URL is that the "@" character might > > be a bit problematic, since it already has a role in the HTTP > > authentication URL format. > > What specific issue do you see since it would be URL-encoded ofc? > Ah, right. We will have '%40' (escaped '@') in every such URL, but it's not that big of a thing. Some devs might forget to escape it if they happen to build it by hand, but again, minor stuff. Thanks, Eduard > > > Another (simplistic) idea would be to use some sort of separator to > > distinguish the attachment reference part from the zip path inside the > > URL's path. > > > > Possible separators might be > > - e.g. '~', suggested by Marius (/something.zip/~/path/inside/zip/file) > > - more complex keywords e.g. 'vfsContent' or whatever > > (/something.zip/vfsContent/path/inside/zip/file) > > - empty path element (/something.zip//path/inside/zip/file) > > -- this has the benefit that an empty entity can not exist, so no > conflict > > -- the downside is that multiple slashes might be handled inconsistently > by > > either browsers or web/application servers so it may not be a reliable > > option. Also, relative paths might behave unexpectedly when combined with > > empty path elements. > > > > The main issue with the separator is that you need to perform 1-2 > > additional DB queries to make sure it was not a reference to a page > (space) > > having the same name as 'separator' inside an 'attachmentName.zip' space > so > > this case would have to be handled properly. > > The only way to avoid this would be to blacklist the separator from being > > used as entity name, but I don`t think we want to do that and we > currently > > don`t have blacklisted characters (or keywords) in entity names. > > Indeed. > > Thanks > -Vincent > > > Thanks, > > Eduard > > > > On Mon, Nov 16, 2015 at 11:23 AM, [email protected] > > wrote: > > > > > > > > > > > > > > > > > > > > On 16 Nov 2015 at 09:57:24, Marius Dumitru Florea ( > > > [email protected](mailto:[email protected])) > > > wrote: > > > > > > > On Fri, Nov 13, 2015 at 8:19 PM, [email protected] > > > > wrote: > > > > > > > > > Hi Edy, > > > > > > > > > > On 13 Nov 2015 at 19:06:33, Eduard Moraru ([email protected] > > > (mailto: > > > > > [email protected])) wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > About the URL format, why not implement it as a REST extension > of the > > > > > > /attachment/ resource? > > > > > > > > > > > > Maybe .../attachments/{attachmentName}/zipExplorer/{zipPath} or > > > something > > > > > > like that. > > > > > > > > > > That’s a good generic remark: we need to decide what to do going > > > forward > > > > > between REST-module type of URLs and Action-module type of URLs. > > > > > > > > > > Ideally I think we would use the following strategy: > > > > > * For human-readable URLs: use the Action-module type > > > > > * For programmatic URLs (get, webjars, zip, etc): use the > REST-module > > > type > > > > > > > > > > However, right now the Action-module type (Resource module to be > > > precise) > > > > > are much more powerful than the REST ones (see > > > > > http://design.xwiki.org/xwiki/bin/view/Design/ActionModule). For > > > example > > > > > you can execute action after others, or before or replacing them. > You > > > vzn > > > > > register new actions dynamically in Extensions (which is not > possible > > > as > > > > > REST components ATM). etc. > > > > > > > > > > So while I agree with you in general, I wouldn’t want to do this > now > > > for > > > > > the zip module because of this. > > > > > > > > > > Now, we shouldn’t care too much about this since it’s only > > > implementation > > > > > details. What we should care about is the URL format. > > > > > > > > > > Right now the format I’m proposing is: > > > > > > > > > > > > > > > > > > > .../zip/space1.space2.page@attachment/path/inside/zi > > > > > > > > > > > > > Be careful with putting the serialized (attachment) reference in the > URL. > > > > Special characters are escaped in the reference using \ (backslash) > which > > > > may cause problems even when URL encoded (e.g. for Tomcat). See > > > > > > > > http://jira.xwiki.org/browse/XWIKI-11528?focusedCommentId=84410&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-84410 > > > > > > Thanks Marius for raising this: I’ve sent a mail on this topic: > > > http://markmail.org/message/ft3245cbq4ehedct > > > > > > However this issue is more global than for this use case and it should > be > > > fixed globally. I don’t think it should affect too much this > discussion. > > > > > > Thanks > > > -Vincent > > > > > > > Thanks, > > > > Marius > > > > > > > > > > > > > > > > > > Following your suggestion would lead to something like (of course > if we > > > > > were using the REST module we wouldn’t have the “zip” action): > > > > > > > > > > > > > > > > > > > …/zip/wikis/wiki/spaces/space1/spaces/space2/pages/page/attachments/attachment/zippath/some/file/in/zip > > > > > > > > > > I’m not sure which one is best. All I know is that I find this > later > > > > > format to be very verbose. But this is the case for our REST format > > > ATM. > > > > > > > > > > We could imagine supporting an alternate RESTful format like: > > > > > > > > > > /rest/reference/space1.space2.page@attachment > /zippath/some/file/in/zip > > > > > > > > > > So taking all this into account, at this point in time, I think I > > > prefer > > > > > my proposal so far. > > > > > > > > > > WDYT? > > > > > > > > > > I also agree that we should clarify our strategy and have some > action > > > plan > > > > > to improve the REST module to make it really component-based and > merge > > > it > > > > > with the Resource/URL modules. > > > > > > > > > > Thanks and have a great weekend! :) > > > > > -Vincent > > > > > > > > > > > Thanks, > > > > > > Eduard > > > > > > > > > > > > On Fri, Nov 13, 2015 at 5:08 PM, [email protected] > > > > > > wrote: > > > > > > > > > > > > > Hi devs, > > > > > > > > > > > > > > Following the need to support Nested Spaces in the Zip Explorer > > > plugin > > > > > > > (see http://jira.xwiki.org/browse/XWIKI-12448) I think it’s > time > > > to > > > > > bite > > > > > > > the bullet and reimplement the feature using components ( > > > > > > > http://jira.xwiki.org/browse/XWIKI-12815). > > > > > > > > > > > > > > I’ve started a design page at > > > > > > > > > > http://design.xwiki.org/xwiki/bin/view/Proposal/ZipExplorerComponent > > > > > > > > > > > > > > I’m especially interested in ensuring that I have all use cases > > > taken > > > > > into > > > > > > > account. > > > > > > > > > > > > > > Could you have a quick look and see whether it looks fine or > not? > > > > > > > > > > > > > > I’m also interested in any feedback on the URL format + API. > > > > > > > > > > > > > > Thanks a lot > > > > > > > -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
