Hi,
There are 2 reasons I want to stop caching documents when they are stored.
1. Coherence, it should be impossible for the cache to have a different entry than the store.
Suppose a document is stored and the storage fails without throwing any error, the document will appear to be
stored correctly until the cache is purged. Another more likely scenario is that the document loaded from the
store is slightly different than the document saved to the store and thus the cache will be lying.
2. Performance, when an attachment is added to a document, the document contains all of the attachment's
content. My analysis tells me switching to holding the content with a soft reference would be quite complex
and proving that nothing depends on the attachment content not being null is very difficult.
The proposed change will prevent the attachment content from ever being stored in the cache and provide an
improvement in allowable cache capacity and memory footprint.
WDYT?
Caleb
Hi everyone,
In the rendering module we need to progress on some issues. For example I'd like to implement support for relative URLs:
http://jira.xwiki.org/jira/browse/XWIKI-3611
This means introducing XWiki Syntax 2.1 which will a point release after XWiki Syntax 2.0. Of course any page in XWiki Syntax 2.0 will be able to be converted in 2.1 syntax.
FTM we haven't fully defined yet the full list of changes in XWiki Syntax 2.1.
The idea is to introduce in 2.5 an experimental XWiki Syntax 2.1 syntax to show it's not finished yet (in the UI the syntax name will be "XWiki Syntax 2.1 (experimental)") and start introducing changes, the first one being support for relative URLs.
WDYT?
Thanks
-Vincent
Hi everybody,
I am writing to the list in order to discuss an architectural choice
which I had the chance to talk about with Vincent.
In the framework of the Wiki3.0 [1] projects we are building a social
extension of XWiki that will introduce social-oriented functionalities
in the platform.
One of these functionalities are related to "Workspaces" which have been
defined as a "virtual place where a group of users can collaborate on a
given topic. A workspace implicitly defines a social-network which
consists of the users that participate to the activities in the context
of a given workspace."
A workspace, besides having a set of users subscribed to it, has also a
set of applications that are related to the type of the interactions
that are carried in the workspace itself (e.g., a blog, a meeting
manager, etc.)
This is the abstract picture. At the architectural level this could be
implemented in different ways.
What we briefly discussed with Vincent is that workspaces could be
easily handled by using XEM. In this case, instead of having a mapping
Workspace <-> space in a single Wiki we would have a Workspace <-> wiki
in a multiwiki setup managed by XEM.
This has several advantages since the current features can be already
leveraged and extended in order to implement workspace functionalities:
1) existing applications are already ready-to-deploy
2) rights management is already enough to manage subscriptions
3) being a workspace a full wiki this gives the users more flexibility
(e.g., they are not constrained to a single space for organizing their
content)
In this picture the main wiki could be used only as a "user container"
and will have all the functionalities (UI + code) to manage workspaces'
lifecycle (i.e., creation, deletion). Additional functionalities will
the be present in the workspace wiki for actually managing the workspace
(i.e., adding/removing members, subscription management for open
workspaces, workspace attributes management and so on).
Initially I haven't thought about workspaces as wikis in a XEM context
by the idea is very powerful and I think we should build it in this way.
WDYT?
Thanks,
-Fabio
[1] https://wiki30.xwikisas.com
Hi devs,
I propose to remove the old rights interface (called "stable"). This
interface was replaced by the current version (the one with livetable)
in XWiki 1.2 several years ago, but the old code is still there.
The following files are affected:
web/standard/**/templates/rightsUI.vm
applications/administration/**/XWiki/AdminGroupsSheet.xml
applications/administration/**/XWiki/AdminUsersSheet.xml
applications/administration/**/XWiki/XWikiGroupSheet.xml
applications/panels/**/Panels/GlobalRightsEditorWelcome.xml
applications/panels/**/Panels/RightsEditorWelcome.xml
core/xwiki-core/**/plugin/rightsmanager/RightsManagerPluginApi.java
The Java file contains the method getDefaultUi() to read the
xwiki.rights.defaultui configuration property, the rest has parts of the
interface.
WDYT?
Alex
Hi devs,
I just realized that there was no official roadmap proposal for XE 2.5
yet, since Vincent, the usual release manager, is on holidays. I
volunteered for performing the releases, so I'll assume the release
manager role as well until Vincent returns.
Proposed features for the 2.5 release:
- Improved wiki dashboard
- Improved edit modes UI
- Office Preview
- Action menu improvements (Caty, JV, Sergiu)
- Export UI improvements (Caty, Sergiu)
- "Email this page" feature (Sergiu)
- User Directory
Generic stuff:
- More UI standards (avatars, icons, forms)
- Improved performance
- Improved security
- WYSIWYG bugfixing and optimization
- More 2.0 macros
Possible new features:
- Portlet integration (Marius)
- Layout Themes (Sergiu)
- Gadgets (Anca)
- Wiki Import (Thomas)
Proposed dates:
- 2.5M1: 30 Aug
- 2.5M2: 27 Sep
- 2.5RC1: 11 Oct
- 2.5RC2/Final: 25 Oct
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi,
I posted http://jira.xwiki.org/jira/browse/XE-700 a couple of days ago
and am writing now because more and more of the Balsamiq Mockups for
XWiki users are attempting or would like to migrate to 2.4 but have
pages with mockups embedded using #includeMacros. I'd like to know if
#includeMacros is definitely not going to be supported from 2.4
onwards or if this is a bug that will be fixed at some point. We can
update the plugin (already have actually) to use the recommended
syntax for new mockups but still have the issue of dealing with
existing pages. I would also like your thoughts on a simple workaround
which ideally we could ask our users / wiki admins to do.
Thanks,
Luis
----- "Fabio Mancinelli" <fabio.mancinelli(a)xwiki.com> wrote:
> On 09/02/2010 11:13 AM, Ecaterina Valica wrote:
>
> >>> Another little remark: I think that user (and application)
> updates
> >>> should be expanded by default without needing the user to click in
> order
> >>> to show the actual message.
> >
> > If we gonna have in the future something like this
> >
> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/AvatarsProposa…
> > where we can put also the status in, then in order to see the status
> message
> > you could just hover the name of the user and you are not gonna have
> to
> > click on it.
> >
> > For me, expanding statuses and application and not pages is
> inconsistency.
> >
> > Also, we can have in the filters (don't know where) an "Expand /
> Collapse
> > All" option for people that have a certain preference in
> displaying.
> >
> >
>
> IMHO, I think that the information and functionality of the "Changed
> status" toggle adds unneeded complexity: when the user sees the avatar
>
> icon in the activity stream she already knows that a "status has
> changed", this information is already conveyed by the fact that an
> entry
> of that type exists! Moreover a status update will contain, il 90% of
>
> the cases, a single message so 90% of the "Changed status" expansion
> will contain only 1 item.
>
> For documents is different because changes can be a lot so the "4
> changes by 3 contributors" conveys additional information.
>
> What could be done to solve the "consistency" issue is to always
> display
> the first item and hide the others in the collapsed list.
>
> * So for single status updates you will have the status update
> directly
> displayed.
+1
And it would not shock me either if the style differs a little from the document updates : no icon but directly the user picture, a bit bigger than icons.
Jerome.
>
> * For multiple status updates by the same user you will have the last
>
> one + a "3 more..." hidden behind the toggle
>
> * For document updates with a single change you will just have the
> change that has been done
>
> * For documents with multiple changes you will have just the latest
> change + "X more changes by Y contributors" toggle with the rest.
>
> This would also solve the problem of having an activity stream
> filtered
> only by "status updates" where the user has to click every time on
> "expand all" in order to actually have the information which should be
>
> available (and expected) by default.
>
> WDYT?
>
> -Fabio
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
----- "Vincent Massol" <vincent(a)massol.net> wrote:
> Thanks Sergiu for taking over during my holidays.
>
> Now let's see where we stand today. Could everyone with tasks to be
> implemented for 2.5 please provide a one line summary under each item
> below stating the status and whether there'll be issues to complete
> the implementation during the defined timeframe?
>
> - Improved edit modes UI (Sergiu/Marta)
> - Office Preview (Marius)
> - Action menu improvements (Caty, JV, Sergiu)
> - Export UI improvements (Caty, Sergiu)
> - "Email this page" feature (Sergiu)
> - User Directory (JV or Jerome - can't remember - to commit Raluca's
> work)
> - Portlet integration (Marius)
> - Dashboards/Gadgets (Anca)
> - More UI standards (avatars, floating document menu, icons, forms)
> (Caty + Sergiu/Marta)
> - Improved performance (Caleb, Alex?)
> - Improved security (Caleb, Alex)
> - WYSIWYG bugfixing and optimization (Marius)
> - More 2.0 macros (JV)
> - Rendering bugfixing and improvements (Thomas)
> - Extension Manager 1st very basic version (Thomas)
> - Recent changes (Caty, JV)
> - Localization module (Sergiu or Thomas?)
>
> Possible New features (optional):
> - Layout Themes (Sergiu)
> - Wiki Import (Thomas)
> - spotlight like search (Jerome)
I can't promise anything since I will be off most of the remaining 2.5 timeframe,
BUT I will try as much as I can to make it happen, at least I will commit what we have already in the sandbox and start cleaning it.
Will keep you informed,
Jerome.
>
> Also, we need to release 2.5M1 ASAP (waiting for JV to come back from
> holiday tomorrow.
>
> Thanks
> -Vincent
>
> On Aug 24, 2010, at 12:17 AM, Sergiu Dumitriu wrote:
>
> > Hi devs,
> >
> > I just realized that there was no official roadmap proposal for XE
> 2.5
> > yet, since Vincent, the usual release manager, is on holidays. I
> > volunteered for performing the releases, so I'll assume the release
>
> > manager role as well until Vincent returns.
> >
> > Proposed features for the 2.5 release:
> >
> > - Improved edit modes UI (Sergiu/Marta)
> > - Office Preview (Marius)
> > - Action menu improvements (Caty, JV, Sergiu)
> > - Export UI improvements (Caty, Sergiu)
> > - "Email this page" feature (Sergiu)
> > - User Directory (JV or Jerome - can't remember - to commit Raluca's
> work)
> > - Portlet integration (Marius)
> > - Gadgets (Anca)
> >
> > Generic stuff:
> > - More UI standards (avatars, icons, forms) (Caty + Sergiu/Marta)
> > - Improved performance (Caleb)
> > - Improved security (Caleb, Alex)
> > - WYSIWYG bugfixing and optimization (Marius)
> > - More 2.0 macros (JV)
> >
> > Possible New features:
> > - Layout Themes (Sergiu)
> > - Wiki Import (Thomas)
> >
> > Proposed dates:
> >
> > - 2.5M1: 30 Aug
> > - 2.5M2: 27 Sep
> > - 2.5RC1: 11 Oct
> > - 2.5RC2/Final: 25 Oct
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs