23 Aug
2011
23 Aug
'11
6:29 p.m.
Hello again,
I would like to introduce a new module in platform : xwiki-platform-thumbnails.
The idea of the module is to provide means of handling thumbnails in
XWiki. Right now the main purpose is to expose APIs to retrieve
thumbnails URLs for images stored as attachments. This module first
use will be to generate thumbnails of user avatars. In this scenario,
it will also introduce a performance improvement compared to today's
way of computing avatar URLS, since the module caches both the
property values (the fact that user X has set an avatar Z.png) and the
thumbnail URL for this avatar.
I've already pushed it in a feature branch/. You can check in
particular
https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba…
and all commits in the branch at
https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails
Let me know what you think.
--
Jerome Velociter
Winesquare
http://www.winesquare.net/
24 Aug
24 Aug
9:11 a.m.
Hi Jerome,
On Aug 23, 2011, at 6:29 PM, Jerome Velociter wrote:
Hello again,
I would like to introduce a new module in platform : xwiki-platform-thumbnails.
The idea of the module is to provide means of handling thumbnails in
XWiki. Right now the main purpose is to expose APIs to retrieve
thumbnails URLs for images stored as attachments. This module first
use will be to generate thumbnails of user avatars. In this scenario,
it will also introduce a performance improvement compared to today's
way of computing avatar URLS, since the module caches both the
property values (the fact that user X has set an avatar Z.png) and the
thumbnail URL for this avatar.
I've already pushed it in a feature branch/. You can check in
particular
https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba…
and all commits in the branch at
https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails
Let me know what you think.
I'm offline in the train right now so I cannot check the API you propose so my
comments/questions are general:
* Should this module be limited to thumbnails only or can we make it a more generic module
in charge of handling image manipulations (and caching) in general (and thus including
thumbnails)? I see this as replacing the old image plugin.
* Re caching we should have an "active cache" working like this:
- Save the location of the image as part of the cache key. When the image is a page
attachment, then the location is an Entity Reference to an attachment. We could/should
also handle images on the FS.
- Have the cache be an EventListener listening to attachment events and have it refresh
its cache when there's an attachment udpate
- Save the transformation details as part of the cache key.
- Save the modified images on the FS (FS cache) - that's the cache value.
* We should replace all calls to the image plugin to use this new module and then move the
image plugin to the legacy module.
* As for caching information that user X has an avatar named Z.png I think this is not
generic enough and shouldn't be in this image manipulation module. IMO it should be in
a xwiki-user module in charge of handling users, and indeed that module could have a cache
of user information in memory to prevent user document loading.
WDYT?
Thanks
-Vincent
10:41 a.m.
Hi Vincent,
On Wed, Aug 24, 2011 at 9:11 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Jerome,
On Aug 23, 2011, at 6:29 PM, Jerome Velociter wrote:
The image manipulation module was the idea I had at first indeed.
Unfortunately I later realized there were too much pre-requisites in
order for me to do it in the timeframe I can dedicate to it. For
example, there is the need of hooking a URI to an image
transformation. Which means I would have to also invest time in the
action module (I imagine).
In the end I decided to leave the image transformations to the old
image plugin, and go with a module dedicated to thumbnails for the
rest - thus the name.
Hello again,
I would like to introduce a new module in platform : xwiki-platform-thumbnails.
The idea of the module is to provide means of handling thumbnails in
XWiki. Right now the main purpose is to expose APIs to retrieve
thumbnails URLs for images stored as attachments. This module first
use will be to generate thumbnails of user avatars. In this scenario,
it will also introduce a performance improvement compared to today's
way of computing avatar URLS, since the module caches both the
property values (the fact that user X has set an avatar Z.png) and the
thumbnail URL for this avatar.
I've already pushed it in a feature branch/. You can check in
particular
https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba…
and all commits in the branch at
https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails
Let me know what you think.
I'm offline in the train right now so I cannot check the API you propose so my
comments/questions are general:
* Should this module be limited to thumbnails only or can we make it a more generic
module in charge of handling image manipulations (and caching) in general (and thus
including thumbnails)? I see this as replacing the old image plugin.
* Re caching we should have an "active cache" working like this:
- Save the location of the image as part of the cache key. When the image is a page
attachment, then the location is an Entity Reference to an attachment. We could/should
also handle images on the FS.
- Have the cache be an EventListener listening to attachment events and have it refresh
its cache when there's an attachment udpate
- Save the transformation details as part of the cache key.
- Save the modified images on the FS (FS cache) - that's the cache value.
* We should replace all calls to the image plugin to use this new module and then move
the image plugin to the legacy module.
* As for caching information that user X has an avatar named Z.png I think this is not
generic enough and shouldn't be in this image manipulation module. IMO it should be in
a xwiki-user module in charge of handling users, and indeed that module could have a cache
of user information in memory to prevent user document loading.
No, that's not exactly what it's about. It's about caching information
that property X points to an attachement reference Y. The avatar is
just an illustration of that. IMO this need is generic enough when
speaking about thumbnails. For a true image module, maybe not.
Now the question is do we estimate this thumbnails module (that now
rely on the old image plugin to actually do transformations) is
acceptable enough to be integrated or should we wait until having a
true image module in order to support nice thumbnails. Personnally
while I definitetely share the vision of it. I won't have the time
necessary to work on that generic image module in 3.2 timeframe (and
likely not in 3.3). If we prefer to wait that's also fine by me : I
can live with a patch on the image plugin and the thumbnails module as
an external module.
Jerome.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jerome Velociter
Winesquare
http://www.winesquare.net/
10:56 a.m.
Le 24 août 2011 à 10:41, Jerome Velociter a écrit :
> * Should this module be limited to thumbnails only
or can we make it a more generic module in charge of handling image manipulations (and
caching) in general (and thus including thumbnails)? I see this as replacing the old image
plugin.
Just out of curiosity, is this plugin supposed to work properly within headless servers
and out of them?
I tend to meet often image manipulations tools that rely on a GUI which is a problem for
many servers.
At the end, everyone does it with ImageMagick (which is a fairly powerful tool).
The name "thumbnails" made me think of thumbnails of pages, which is another
area in evolution but would require an amount more work.
paul
11:03 a.m.
On Wed, Aug 24, 2011 at 10:56 AM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
Le 24 août 2011 à 10:41, Jerome Velociter a écrit :
Right now it's using the old image plugin, so java.awt classes.
While I was thinking about going for an image module, Sergiu pointed
me towards Apache xml graphics library.
Using an external tool such as image magic as an alternate
implementation could also be interesting indeed.
> * Should this module be limited to thumbnails
only or can we make it a more generic module in charge of handling image manipulations
(and caching) in general (and thus including thumbnails)? I see this as replacing the old
image plugin.
Just out of curiosity, is this plugin supposed to work properly within headless servers
and out of them?
I tend to meet often image manipulations tools that rely on a GUI which is a problem for
many servers.
At the end, everyone does it with ImageMagick (which is a fairly powerful tool).
The name "thumbnails" made me think of thumbnails of pages, which is another
area in evolution but would require an amount more work.
What do you mean by that ? Visual thumbnail representation of a document ?
Jerome
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jerome Velociter
Winesquare
http://www.winesquare.net/
11:10 a.m.
Le 24 août 2011 à 11:03, Jerome Velociter a écrit :
Exactly.
I just wanted to warn that it might be a confusion.
paul
On Wed, Aug 24, 2011 at 10:56 AM, Paul Libbrecht
<paul(a)hoplahup.net> wrote:
So that NEEDS a desktop, right?
Better warn folks and suggest to use, on unix servers, vncserver... it's a bit of a
tricky thing in terms of management but it can work well.
Le 24 août 2011 à 10:41, Jerome Velociter a écrit :
Right now it's using the old image plugin, so java.awt classes. > * Should this module be limited to thumbnails
only or can we make it a more generic module in charge of handling image manipulations
(and caching) in general (and thus including thumbnails)? I see this as replacing the old
image plugin.
Just out of curiosity, is this plugin supposed to work properly within headless servers
and out of them?
I tend to meet often image manipulations tools that rely on a GUI which is a problem for
many servers.
At the end, everyone does it with ImageMagick (which is a fairly powerful tool). While I was thinking about going for an image module,
Sergiu pointed
me towards Apache xml graphics library.
FOP is for servers... that should work.
Using an external tool such as image magic as an
alternate
implementation could also be interesting indeed.
It's really easy to use! But maturation to control the process finely is not the
easiest I found.
We've used in i2geo's Vignette library (where users shoot vignettes of their
resource in use, it's uploaded, it's scaled-down and shaded, ready to be displayed
in the carousel, groovy, applets, gwt). i2geo.net and
http://svn.activemath.org/intergeo/Platform/Vignettes/ )
The name
"thumbnails" made me think of thumbnails of pages, which is another area in
evolution but would require an amount more work.
What do you mean by that ? Visual thumbnail representation of a document ?
11:18 a.m.
On Wed, Aug 24, 2011 at 11:10 AM, Paul Libbrecht <paul(a)hoplahup.net> wrote:
Exactly.
Yeah that would be something cool. If I would to be looking into it,
I'd look at what can be done with processing.js to make a "preview"
(or thumbnail) of an HTML page. (Not sure that's the best, but that's
where I would start :) )
Le 24 août 2011 à 11:03, Jerome Velociter a écrit :
No, at least not the use we are doing of those classes. I'm using it
headless on a unix system with no special configuration for example.
On Wed, Aug 24, 2011 at 10:56 AM, Paul Libbrecht
<paul(a)hoplahup.net> wrote:
So that NEEDS a desktop, right?
Better warn folks and suggest to use, on unix servers, vncserver... it's a bit of a
tricky thing in terms of management but it can work well.
Le 24 août 2011 à 10:41, Jerome Velociter a écrit :
Right now it's using the old image plugin, so java.awt classes. > * Should this module be limited to thumbnails
only or can we make it a more generic module in charge of handling image manipulations
(and caching) in general (and thus including thumbnails)? I see this as replacing the old
image plugin.
Just out of curiosity, is this plugin supposed to work properly within headless servers
and out of them?
I tend to meet often image manipulations tools that rely on a GUI which is a problem for
many servers.
At the end, everyone does it with ImageMagick (which is a fairly powerful tool). While I was thinking about going for an image
module, Sergiu pointed
me towards Apache xml graphics library.
FOP is for servers... that should work.
Using an external tool such as image magic as an
alternate
implementation could also be interesting indeed.
It's really easy to use! But maturation to control the process finely is not the
easiest I found.
We've used in i2geo's Vignette library (where users shoot vignettes of their
resource in use, it's uploaded, it's scaled-down and shaded, ready to be displayed
in the carousel, groovy, applets, gwt). i2geo.net and
http://svn.activemath.org/intergeo/Platform/Vignettes/ )
The name
"thumbnails" made me think of thumbnails of pages, which is another area in
evolution but would require an amount more work.
What do you mean by that ? Visual thumbnail representation of a document ? I just wanted to warn that it might be a confusion.
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jerome Velociter
Winesquare
http://www.winesquare.net/
7 Sep
7 Sep
2:54 p.m.
On Wed, Aug 24, 2011 at 10:41 AM, Jerome Velociter
<jerome(a)winesquare.net> wrote:
Hi Vincent,
On Wed, Aug 24, 2011 at 9:11 AM, Vincent Massol <vincent(a)massol.net> wrote:
Any other opinions ?
Jerome
Hi Jerome,
On Aug 23, 2011, at 6:29 PM, Jerome Velociter wrote:
The image manipulation module was the idea I had at first indeed.
Unfortunately I later realized there were too much pre-requisites in
order for me to do it in the timeframe I can dedicate to it. For
example, there is the need of hooking a URI to an image
transformation. Which means I would have to also invest time in the
action module (I imagine).
In the end I decided to leave the image transformations to the old
image plugin, and go with a module dedicated to thumbnails for the
rest - thus the name.
Hello again,
I would like to introduce a new module in platform : xwiki-platform-thumbnails.
The idea of the module is to provide means of handling thumbnails in
XWiki. Right now the main purpose is to expose APIs to retrieve
thumbnails URLs for images stored as attachments. This module first
use will be to generate thumbnails of user avatars. In this scenario,
it will also introduce a performance improvement compared to today's
way of computing avatar URLS, since the module caches both the
property values (the fact that user X has set an avatar Z.png) and the
thumbnail URL for this avatar.
I've already pushed it in a feature branch/. You can check in
particular
https://github.com/xwiki/xwiki-platform/commit/3f5aa1e24ba00fcc939b73b8f9ba…
and all commits in the branch at
https://github.com/xwiki/xwiki-platform/commits/feature-thumbnails
Let me know what you think.
I'm offline in the train right now so I cannot check the API you propose so my
comments/questions are general:
* Should this module be limited to thumbnails only or can we make it a more generic
module in charge of handling image manipulations (and caching) in general (and thus
including thumbnails)? I see this as replacing the old image plugin.
* Re caching we should have an "active cache" working like this:
- Save the location of the image as part of the cache key. When the image is a page
attachment, then the location is an Entity Reference to an attachment. We could/should
also handle images on the FS.
- Have the cache be an EventListener listening to attachment events and have it refresh
its cache when there's an attachment udpate
- Save the transformation details as part of the cache key.
- Save the modified images on the FS (FS cache) - that's the cache value.
* We should replace all calls to the image plugin to use this new module and then move
the image plugin to the legacy module.
* As for caching information that user X has an avatar named Z.png I think this is not
generic enough and shouldn't be in this image manipulation module. IMO it should be in
a xwiki-user module in charge of handling users, and indeed that module could have a cache
of user information in memory to prevent user document loading.
No, that's not exactly what it's about. It's about caching information
that property X points to an attachement reference Y. The avatar is
just an illustration of that. IMO this need is generic enough when
speaking about thumbnails. For a true image module, maybe not.
Now the question is do we estimate this thumbnails module (that now
rely on the old image plugin to actually do transformations) is
acceptable enough to be integrated or should we wait until having a
true image module in order to support nice thumbnails. Personnally
while I definitetely share the vision of it. I won't have the time
necessary to work on that generic image module in 3.2 timeframe (and
likely not in 3.3). If we prefer to wait that's also fine by me : I
can live with a patch on the image plugin and the thumbnails module as
an external module.
Jerome.
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jerome Velociter
Winesquare
http://www.winesquare.net/
4811
days inactive
4826
days old
7 comments
3 participants
participants (3)
-
Jerome Velociter -
Paul Libbrecht -
Vincent Massol