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? > 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
