6 Dec
2009
6 Dec
'09
9:11 p.m.
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend
(http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
A more generic solution would be to add a notion of Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
However someone could use a some check for a resource that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
7 Dec
7 Dec
12:23 p.m.
Hi
On 12/6/09 9:11 PM, Vincent Massol wrote:
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend
(http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
Why not /xwiki/bin/temporary/Space/Page/SomeResource ?
Its consistent with the way others URL schemes are built (for example
the download action).
I don't think we have a strong need to check against something else than
the view right, do we? (at least in a first version).
wdyt ?
Jerome.
A more generic solution would be to add a notion of Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
However someone could use a some check for a resource that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:11 p.m.
Hi,
On Mon, Dec 7, 2009 at 12:23 PM, Jerome Velociter <jerome(a)xwiki.com> wrote:
Having an action dedicated to temporary files sounds good to me. It could be
useful for plenty of macros in the future (Office document displayer,
formula, graphviz etc...)
I agree with jerome here binding rights for this action to the view right
sounds good enough to me for a first version.
Guillaume
Hi
On 12/6/09 9:11 PM, Vincent Massol wrote:
Sounds nice :-)
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend (
http://ditaa.sourceforge.net/
) but we need an Action to return the
Ditaa-generated image file.
For the chart
macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
Why not /xwiki/bin/temporary/Space/Page/SomeResource ?
Its consistent with the way others URL schemes are built (for example
the download action).
I don't think we have a strong need to check against something else than
the view right, do we? (at least in a first version).
wdyt ?
Jerome.
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
A more generic solution would be to add a notion of Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
However someone could use a some check for a resource that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:20 p.m.
On 12/06/2009 09:11 PM, Vincent Massol wrote:
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend
(http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Currently, most plugins that generate temporary resources don't create
them directly in the workdir, but in a subdirectory (true for chart,
svg, image, graphviz and maybe others), which reduces the risk of
collisions. I'd rather keep this functionality.
Anyway, +1 for having a common action for all generated images. This
will also reduce the need to change the rights class and the struts
config for each new plugin.
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
For the moment, all such resources are generated for being displayed
inside a document, in normal view mode. Thus, I think it's enough to
check if the user has view rights on the document for which the image is
generated. Do you have any other (real) usecase in mind?
But another important issue to keep in mind is cache settings. For good
performance we should allow clients to cache the image, while preventing
other users from accessing a cached resource. Any ideas?
First, we could prevent caching on proxies. This doesn't fix the
following scenario: client logs in, views a resource, then logs out,
leaving the image in the cache.
Second, we could use somewhat short cache settings, like 10 minutes.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
What prevents a user from changing the URL to use a different page name?
In other words, the owner page should not be present just in the URL,
but somehow should be connected to the resource on the server.
One idea would be to hash the page + id and store the resource using
this hash as its name. Problem: hash collisions.
Another idea would be to use a cleaned-up version of the page + id as
the resource name, but we must be careful not to let users generate
colliding resource names (for example wiki:Spa.cePage would collide with
wiki:Space.Page if the cleanup process means just removing special chars).
Or we could combine the two, for more security.
A more generic solution would be to add a notion of
Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
See above, I don't think this complexity is really needed.
However someone could use a some check for a resource
that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
How about this kind of URL?
/xwiki/bin/tempresource/Space/Document/plugin/Sjqh73sjq.png
where plugin is the name of the plugin/component that generated the
image, like svg, chart, graphviz...
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
8 Dec
8 Dec
8:58 a.m.
Hi,
On Dec 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
Exactly. That's why I suggested an alternative below. I was
brainstorming live...
On 12/06/2009 09:11 PM, Vincent Massol wrote:
I agree.
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend
(http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we
can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Currently, most plugins that generate temporary resources don't create
them directly in the workdir, but in a subdirectory (true for chart,
svg, image, graphviz and maybe others), which reduces the risk of
collisions. I'd rather keep this functionality. Anyway, +1 for having a common action for all
generated images. This
will also reduce the need to change the rights class and the struts
config for each new plugin.
Even for view I was thinking that maybe the code could need to check
for 2 rights in some cases. But I agree let's start simple for now.
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which
the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
For the moment, all such resources are generated for being displayed
inside a document, in normal view mode. Thus, I think it's enough to
check if the user has view rights on the document for which the
image is
generated. Do you have any other (real) usecase in mind? But another important issue to keep in mind is cache
settings. For
good
performance we should allow clients to cache the image, while
preventing
other users from accessing a cached resource. Any ideas?
You mean if several people use the same computer?
I don't think we can cache if we really want to be safe. Or the image
would need to be locally encrypted and decrypted with a key but that
sounds overkill.
First, we could prevent caching on proxies. This
doesn't fix the
following scenario: client logs in, views a resource, then logs out,
leaving the image in the cache.
Second, we could use somewhat short cache settings, like 10 minutes.
Yes these are intermediary solutions but they mean it's possible for
someone to view an image he doesn't have the right to view.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
What prevents a user from changing the URL to use a different page
name? In other words, the owner page should not be present
just in the URL,
but somehow should be connected to the resource on the server.
Yep, hence the other proposal below.
One idea would be to hash the page + id and store the
resource using
this hash as its name. Problem: hash collisions.
Another idea would be to use a cleaned-up version of the page + id as
the resource name, but we must be careful not to let users generate
colliding resource names (for example wiki:Spa.cePage would collide
with
wiki:Space.Page if the cleanup process means just removing special
chars).
Or we could combine the two, for more security.
Sounds good to me for a first version.
I'd suggest instead to use the shorter "tmp" to make the URL smaller
and be aligned with other action names:
/xwiki/bin/tmp/<space>/<page>/<module name>/<resource name>
Thanks
-Vincent
A more generic solution would be to add a notion
of Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any
complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
See above, I don't think this complexity is really needed.
However someone could use a some check for a
resource that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution
maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
How about this kind of URL?
/xwiki/bin/tempresource/Space/Document/plugin/Sjqh73sjq.png
where plugin is the name of the plugin/component that generated the
image, like svg, chart, graphviz... 
31 Dec
31 Dec
1:06 p.m.
Hi Devs,
How about this kind of URL?
Is anybody working on this? I'm also in need of this functionality and want
to start working on it.
Please let me know if any of you (vincent?) has already done some work on
it.
- Asiri
/xwiki/bin/tempresource/Space/Document/plugin/Sjqh73sjq.png
where plugin is the name of the plugin/component that generated the
image, like svg, chart, graphviz...
Sounds good to me for a first version.
I'd suggest instead to use the shorter "tmp" to make the URL smaller
and be aligned with other action names:
/xwiki/bin/tmp/<space>/<page>/<module name>/<resource name>
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:09 p.m.
On 12/31/2009 01:06 PM, Asiri Rathnayake wrote:
Hi Devs,
Me too.
How about this kind of URL?
Is anybody working on this? I'm also in need of this functionality and want
to start working on it.
/xwiki/bin/tempresource/Space/Document/plugin/Sjqh73sjq.png
where plugin is the name of the plugin/component that generated the
image, like svg, chart, graphviz...
Sounds good to me for a first version.
I'd suggest instead to use the shorter "tmp" to make the URL smaller
and be aligned with other action names:
/xwiki/bin/tmp/<space>/<page>/<module name>/<resource name>
Please let me know if any of you (vincent?) has
already done some work on
it.
- Asiri
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
1 Jan
1 Jan
11:12 a.m.
If you wanted to do it by writing a component implementing Action instead of
through struts, I have the XWikiServlet working, I can commit the patch if your
interested. I just need to know what the servlet should be mapped to in web.xml
/x/ ?
Caleb
Asiri Rathnayake wrote:
Hi,
Is anybody working on this? I'm also in need of this functionality and want
Ok you can work on it (I'm so generous). Let me know when you are finished
:P
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
to start
working on it.
Me too.
5 Jan
5 Jan
7:22 a.m.
Hi,
On Fri, Jan 1, 2010 at 3:42 PM, Caleb James DeLisle <
calebdelisle(a)lavabit.com> wrote:
If you wanted to do it by writing a component
implementing Action instead
of
through struts, I have the XWikiServlet working, I can commit the patch if
your
interested.
Yup, that would be nice. But I think this will take some time (discussions,
proposals, votes etc.).
- Asiri
8:39 p.m.
Yes it does sound like it will be too much waiting. It's unfortunate that the
old core has to be added to, but at the moment I see no way around it.
Caleb
Asiri Rathnayake wrote:
Hi,
On Fri, Jan 1, 2010 at 3:42 PM, Caleb James DeLisle <
calebdelisle(a)lavabit.com> wrote:
If you wanted to do it by writing a component
implementing Action instead
of
through struts, I have the XWikiServlet working, I can commit the patch if
your
interested.
Yup, that would be nice. But I think this will take some time (discussions,
proposals, votes etc.).
- Asiri
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
29 Apr
29 Apr
12:07 p.m.
Hi All,
Sorry about digging this up now but I need this if I'm to get started with
officepreview integration.
How about this kind of URL?
One small remark: in officeimporter we need to be capable of previewing
multiple attachments on the same document. And to make things worse, each
attachment might be exploded into multiple artifacts (image files). So the
trailing <resource name> segment of above URL might pose collision issues.
There are two ways to avoid this:
1. Make sure <resource name> is unique for each image file generated (UUID).
2. Change the URL to something like below:
/xwiki/bin/tmp/<space>/<page>/<module name>/path/to/resource
Now, about protecting against a user simply changing <space> and <page>
segments of above URL and getting access to a file to which he should not
have access:
We can organize the files inside working directory so that the internal path
starts with something like $WORK_DIR/wiki/space/page? or even
$WORK_DIR/SHA_1(wiki)/SHA_1(space)/SHA_1(page)? (in case if there needs to
be some cleaning of wiki,space or page names)
I'm only thinking out lound here and would like your comments on this. We
really need this functionality asap.
Thanks.
- Asiri
/xwiki/bin/tempresource/Space/Document/plugin/Sjqh73sjq.png
where plugin is the name of the plugin/component that generated the
image, like svg, chart, graphviz...
Sounds good to me for a first version.
I'd suggest instead to use the shorter "tmp" to make the URL smaller
and be aligned with other action names:
/xwiki/bin/tmp/<space>/<page>/<module name>/<resource name>
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
26 May
26 May
6:34 p.m.
Hi Devs,
I have implemented tempresource action and it is attached here:
http://jira.xwiki.org/jira/browse/XWIKI-5227
If you are all ok with this, I can go ahead and commit (I thought it could
benefit from a small review).
Thanks.
- Asiri
14 Dec
14 Dec
5:21 p.m.
Hi, Vincent:
Please don't be mad at me. I think it's a cool trick. But I don't think
rendering ascii graph into bitmap will add too much information.
And ordinary users will still find it hard to use.
How about embedding a AJAX or flash based graphics editor? I know there are
some good ones, but I don't know whether there are some open source
alternatives.
Here are some live demos:
http://www.lucidchart.com/documents/demo
http://www.drawanywhere.com/demo.aspx
And the best one: http://www.gliffy.com/ which requires an account.
On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
Part I
=====
I've started implementing a Ditaa Macro over the weekend (
http://ditaa.sourceforge.net/
) but we need an Action to return the Ditaa-generated image file.
For the chart macro we're using the charting action but I think we can
make this generic and instead introduce a tmp (or temp or tmpresource
or ...) action instead that would return any resource located in the
xwiki temporary directory.
For ex:
/xwiki/bin/tmp/SomeResource
would return SomeResource found in
container.getApplicationContext().getTemporaryDirectory().
Part II
=====
The only thing to be careful about is to not be able to read what's
for another user and for which you don't have access to see it. For
example an image generated by the chart macro for a page for which the
user doesn't have view rights. This can be partially solved by
ensuring that file names include a generated token. However the pb is
that this token cannot be unique since, for ex, generated image need
to be shared to anyone having the rights to view a page.
<brainstomring mode>
A solution I see would be to include the "rights" to check + the full
page name in the URL, in addition to the resource. For example:
/xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
A more generic solution would be to add a notion of Check Handler,
i.e. code that would perform the check. For example in the previous
solution it's not possible to check for 2 permissions, nor any complex
scheme. This would mean something like:
/xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
Ex: /xwiki/bin/tmp/simple/SomeResource?
checkPermission="view"&checkDocument="wiki:Space.Page"
Implementation: A component with a role hint of "simple" would be
looked-up and the check logic delegated to it.
However someone could use a some check for a resource that wasn't
meant to be used for that resource.
Thus the check and its params should probably instead be included in
the resource name with some algorithm instead. Thus the solution maybe
to have a high level API to create a resource name and that API would
take a Check Handler hint + some arbitrary params and that API would
generate a resource name with these added. For ex something like::
"SomeResource-simple-view-wiki:Space.Page" (or any other format).
Another solution would be to follow a completely different direction
and for example to introduce a new XDOM representation for a TMP-
image, i.e. in addition to URLImage and DocumentImage, to add a
TemporaryImage implementation.
</brainstomring mode>
WDYT about these 2 ideas and especially about Part I since I would
need that sooner rather than later to implement the Ditaa macro, and
Part II is already a problem today.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
-- Zhaolin Feng
-- www.mapbar.com
-- Currahee! We stand alone together!
5:34 p.m.
Hi Zhalin,
On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote:
Hi, Vincent:
Please don't be mad at me.
:)
I think it's a cool trick. But I don't think
rendering ascii graph into bitmap will add too much information.
The mail wasn't about Ditaa. It was about introducing a temresource
action.
And ordinary users will still find it hard to use.
How about embedding a AJAX or flash based graphics editor? I know
there are
some good ones, but I don't know whether there are some open source
alternatives.
Here are some live demos:
http://www.lucidchart.com/documents/demo
http://www.drawanywhere.com/demo.aspx
And the best one: http://www.gliffy.com/ which requires an account.
Yes Gliffy is great. I'd love to have it. When can you start
implementing the integration? :)
Thanks
-Vincent
On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
> Hi,
>
> Part I
> =====
>
> I've started implementing a Ditaa Macro over the weekend (
> http://ditaa.sourceforge.net/
> ) but we need an Action to return the Ditaa-generated image file.
> For the chart macro we're using the charting action but I think we
> can
> make this generic and instead introduce a tmp (or temp or tmpresource
> or ...) action instead that would return any resource located in the
> xwiki temporary directory.
>
> For ex:
> /xwiki/bin/tmp/SomeResource
>
> would return SomeResource found in
> container.getApplicationContext().getTemporaryDirectory().
>
> Part II
> =====
>
> The only thing to be careful about is to not be able to read what's
> for another user and for which you don't have access to see it. For
> example an image generated by the chart macro for a page for which
> the
> user doesn't have view rights. This can be partially solved by
> ensuring that file names include a generated token. However the pb is
> that this token cannot be unique since, for ex, generated image need
> to be shared to anyone having the rights to view a page.
>
> <brainstomring mode>
>
> A solution I see would be to include the "rights" to check + the full
> page name in the URL, in addition to the resource. For example:
>
> /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
>
> A more generic solution would be to add a notion of Check Handler,
> i.e. code that would perform the check. For example in the previous
> solution it's not possible to check for 2 permissions, nor any
> complex
> scheme. This would mean something like:
>
> /xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
>
> Ex: /xwiki/bin/tmp/simple/SomeResource?
> checkPermission="view"&checkDocument="wiki:Space.Page"
>
> Implementation: A component with a role hint of "simple" would be
> looked-up and the check logic delegated to it.
>
> However someone could use a some check for a resource that wasn't
> meant to be used for that resource.
>
> Thus the check and its params should probably instead be included in
> the resource name with some algorithm instead. Thus the solution
> maybe
> to have a high level API to create a resource name and that API would
> take a Check Handler hint + some arbitrary params and that API would
> generate a resource name with these added. For ex something like::
> "SomeResource-simple-view-wiki:Space.Page" (or any other format).
>
> Another solution would be to follow a completely different direction
> and for example to introduce a new XDOM representation for a TMP-
> image, i.e. in addition to URLImage and DocumentImage, to add a
> TemporaryImage implementation.
>
> </brainstomring mode>
>
> WDYT about these 2 ideas and especially about Part I since I would
> need that sooner rather than later to implement the Ditaa macro, and
> Part II is already a problem today.
>
> Thanks
> -Vincent
>
5:41 p.m.
Vincent:
I know I can't. But I just want to know if someone else have some knowledge
of open source alternatives. If so, the integration is possible then.
On Tue, Dec 15, 2009 at 12:34 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Zhalin,
On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote:
--
-- Zhaolin Feng
-- www.mapbar.com
-- Currahee! We stand alone together!
Hi, Vincent:
Please don't be mad at me.
:)
I think it's a cool trick. But I don't
think
rendering ascii graph into bitmap will add too much information.
The mail wasn't about Ditaa. It was about introducing a temresource
action.
And ordinary users will still find it hard to
use.
How about embedding a AJAX or flash based graphics editor? I know
there are
some good ones, but I don't know whether there are some open source
alternatives.
Here are some live demos:
http://www.lucidchart.com/documents/demo
http://www.drawanywhere.com/demo.aspx
And the best one: http://www.gliffy.com/ which requires an account.
Yes Gliffy is great. I'd love to have it. When can you start
implementing the integration? :)
Thanks
-Vincent
On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
> Hi,
>
> Part I
> =====
>
> I've started implementing a Ditaa Macro over the weekend (
> http://ditaa.sourceforge.net/
> ) but we need an Action to return the Ditaa-generated image file.
> For the chart macro we're using the charting action but I think we
> can
> make this generic and instead introduce a tmp (or temp or tmpresource
> or ...) action instead that would return any resource located in the
> xwiki temporary directory.
>
> For ex:
> /xwiki/bin/tmp/SomeResource
>
> would return SomeResource found in
> container.getApplicationContext().getTemporaryDirectory().
>
> Part II
> =====
>
> The only thing to be careful about is to not be able to read what's
> for another user and for which you don't have access to see it. For
> example an image generated by the chart macro for a page for which
> the
> user doesn't have view rights. This can be partially solved by
> ensuring that file names include a generated token. However the pb is
> that this token cannot be unique since, for ex, generated image need
> to be shared to anyone having the rights to view a page.
>
> <brainstomring mode>
>
> A solution I see would be to include the "rights" to check + the full
> page name in the URL, in addition to the resource. For example:
>
> /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
>
> A more generic solution would be to add a notion of Check Handler,
> i.e. code that would perform the check. For example in the previous
> solution it's not possible to check for 2 permissions, nor any
> complex
> scheme. This would mean something like:
>
> /xwiki/bin/tmp/<check handler name>/<resource name>?<check params>
>
> Ex: /xwiki/bin/tmp/simple/SomeResource?
> checkPermission="view"&checkDocument="wiki:Space.Page"
>
> Implementation: A component with a role hint of "simple" would be
> looked-up and the check logic delegated to it.
>
> However someone could use a some check for a resource that wasn't
> meant to be used for that resource.
>
> Thus the check and its params should probably instead be included in
> the resource name with some algorithm instead. Thus the solution
> maybe
> to have a high level API to create a resource name and that API would
> take a Check Handler hint + some arbitrary params and that API would
> generate a resource name with these added. For ex something like::
> "SomeResource-simple-view-wiki:Space.Page" (or any other format).
>
> Another solution would be to follow a completely different direction
> and for example to introduce a new XDOM representation for a TMP-
> image, i.e. in addition to URLImage and DocumentImage, to add a
> TemporaryImage implementation.
>
> </brainstomring mode>
>
> WDYT about these 2 ideas and especially about Part I since I would
> need that sooner rather than later to implement the Ditaa macro, and
> Part II is already a problem today.
>
> Thanks
> -Vincent
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:48 p.m.
On Dec 14, 2009, at 5:41 PM, Zhaolin Feng wrote:
Vincent:
I know I can't. But I just want to know if someone else have some
knowledge
of open source alternatives. If so, the integration is possible then.
It's also possible with non open source tools. For example we have
Balsamiq integration which is great.
We had a google summer of code for integration a drawing app but it
didn't succeed:
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/CollaborativeBusines…
Thanks
-Vincent
On Tue, Dec 15, 2009 at 12:34 AM, Vincent Massol
<vincent(a)massol.net> wrote:
> Hi Zhalin,
>
> On Dec 14, 2009, at 5:21 PM, Zhaolin Feng wrote:
>
>> Hi, Vincent:
>>
>> Please don't be mad at me.
>
> :)
>
>> I think it's a cool trick. But I don't think
>> rendering ascii graph into bitmap will add too much information.
>
> The mail wasn't about Ditaa. It was about introducing a temresource
> action.
>
>> And ordinary users will still find it hard to use.
>>
>> How about embedding a AJAX or flash based graphics editor? I know
>> there are
>> some good ones, but I don't know whether there are some open source
>> alternatives.
>>
>> Here are some live demos:
>>
>> http://www.lucidchart.com/documents/demo
>> http://www.drawanywhere.com/demo.aspx
>>
>> And the best one: http://www.gliffy.com/ which requires an account.
>
> Yes Gliffy is great. I'd love to have it. When can you start
> implementing the integration? :)
>
> Thanks
> -Vincent
>
>> On Mon, Dec 7, 2009 at 4:11 AM, Vincent Massol <vincent(a)massol.net>
>> wrote:
>>
>>> Hi,
>>>
>>> Part I
>>> =====
>>>
>>> I've started implementing a Ditaa Macro over the weekend (
>>> http://ditaa.sourceforge.net/
>>> ) but we need an Action to return the Ditaa-generated image file.
>>> For the chart macro we're using the charting action but I think we
>>> can
>>> make this generic and instead introduce a tmp (or temp or
>>> tmpresource
>>> or ...) action instead that would return any resource located in
>>> the
>>> xwiki temporary directory.
>>>
>>> For ex:
>>> /xwiki/bin/tmp/SomeResource
>>>
>>> would return SomeResource found in
>>> container.getApplicationContext().getTemporaryDirectory().
>>>
>>> Part II
>>> =====
>>>
>>> The only thing to be careful about is to not be able to read what's
>>> for another user and for which you don't have access to see it. For
>>> example an image generated by the chart macro for a page for which
>>> the
>>> user doesn't have view rights. This can be partially solved by
>>> ensuring that file names include a generated token. However the
>>> pb is
>>> that this token cannot be unique since, for ex, generated image
>>> need
>>> to be shared to anyone having the rights to view a page.
>>>
>>> <brainstomring mode>
>>>
>>> A solution I see would be to include the "rights" to check + the
>>> full
>>> page name in the URL, in addition to the resource. For example:
>>>
>>> /xwiki/bin/tmp/view/wiki:Space.Page/SomeResource
>>>
>>> A more generic solution would be to add a notion of Check Handler,
>>> i.e. code that would perform the check. For example in the previous
>>> solution it's not possible to check for 2 permissions, nor any
>>> complex
>>> scheme. This would mean something like:
>>>
>>> /xwiki/bin/tmp/<check handler name>/<resource name>?<check
params>
>>>
>>> Ex: /xwiki/bin/tmp/simple/SomeResource?
>>>
checkPermission="view"&checkDocument="wiki:Space.Page"
>>>
>>> Implementation: A component with a role hint of "simple" would be
>>> looked-up and the check logic delegated to it.
>>>
>>> However someone could use a some check for a resource that wasn't
>>> meant to be used for that resource.
>>>
>>> Thus the check and its params should probably instead be included
>>> in
>>> the resource name with some algorithm instead. Thus the solution
>>> maybe
>>> to have a high level API to create a resource name and that API
>>> would
>>> take a Check Handler hint + some arbitrary params and that API
>>> would
>>> generate a resource name with these added. For ex something like::
>>> "SomeResource-simple-view-wiki:Space.Page" (or any other format).
>>>
>>> Another solution would be to follow a completely different
>>> direction
>>> and for example to introduce a new XDOM representation for a TMP-
>>> image, i.e. in addition to URLImage and DocumentImage, to add a
>>> TemporaryImage implementation.
>>>
>>> </brainstomring mode>
>>>
>>> WDYT about these 2 ideas and especially about Part I since I would
>>> need that sooner rather than later to implement the Ditaa macro,
>>> and
>>> Part II is already a problem today.
>>>
>>> Thanks
>>> -Vincent
5219
days inactive
5390
days old
16 comments
7 participants
participants (7)
-
Asiri Rathnayake -
Caleb James DeLisle -
Guillaume Lerouge -
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol -
Zhaolin Feng