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/zip 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

On Fri, Nov 13, 2015 at 8:19 PM, [email protected] <[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.atl... 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

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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. 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. Thanks, Eduard On Mon, Nov 16, 2015 at 11:23 AM, [email protected] <[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.atl...

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

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.atl...

...

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

Hi devs, I’ve now renamed the module from Zip Module (xwiki-platform-zip) to VFS Module (xwiki-platform-vfs) at  http://design.xwiki.org/xwiki/bin/view/Proposal/VFSComponent Is it too bold or are you ok with making it that generic? :) I feel it’s better to make it the most generic possible from the onset to avoid too many refactorings in the future and it seems all concepts apply to any VFS. Thanks -Vincent On 14 Nov 2015 at 16:42:11, [email protected] ([email protected](mailto:[email protected])) wrote:

Hi devs,

I think I’ve changed my mind and I’m going to make a proposal for a more generic xwiki-platform-vfs module instead (which will support more formats than just zip: file, http, jar, odf, sfx, tar, zip, etc).

Internally the implementation would be based on TrueVFS (the successor of TrueZIP), see https://truevfs.java.net/

The idea is that this module would offer CRUD (Create, Read, Update, Delete) operations for archive files.

I’ll think more about it and update the design page next week.

If you have any input in the meanwhile please state them! :)

Thanks -Vincent

On 13 Nov 2015 at 16:08:02, [email protected] ([email protected](mailto:[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