Hi Dear,
After a full day of brain storming, I finally submitted my proposal for
Calendar application.
Please have a look on my proposal and let me know how can I improve it.
Thanks for your consideration.
regards,
--
Apurv Gupta
Indian School of Mines University
Hi all.
I would like to participate GSoC and work by XWiki. I am interested in idea
"XWiki Jabber, Google Talk, Skype Integration".
Main aim of described idea is to use some kind of chat rooms. Those chat
rooms should be used for discuss editions and log this discussions to
wiki(please correct me if I am wrong).
What I propose is publish-subscribe mechanism, it is part of
XMPP(Jabber/GTalk) standard. It allows to create messages categorized by
nodes. When message is add, modify or delete from node there is notification
sent to all subscribers (like RSS or ATOM). Main advantage of this solution
is that users may use their jabber accounts for subscribe discussion or
publish something in it.
Here is small comparison:
chat logging:
* To be at home in subject someone have to read all chat log.
pubsub:
* You may subscribe only nodes you are interested in and ignore
uninteresting.
chat logging:
* Chat has specific convention, there is a lot of short messages, statements
are not well-thought-out, there are a lot of misunderstandings and
explanations of it
* After logged all chat. It may be necessary to moderate discussion. We have
to create special tool for this and someone have to do the work.
pubsub:
* When people publish some "post" they have more time to think about it. It
is possible to modify posted unclear statements. Author can even delete
unnecessary own posts (in both situations all subscribers will be notify).
Main disadvantage of pubsub is that it will be more difficult to port this
for Skype and other closed protocols. But users can always use expected
built-in XWiki pubsub client.
Plese give me feedback about this idea.
Jan J. Roman
Hello,
I'm master student in informatics. I would like to apply for JSR-168
full compatibility proposal in this year's GSoC for XWiki.
There's a list of my experience concerning this application:
- Java (mainly databases and web portals - JTA, JPA, JDBC, JBoss, Apache
Tomcat and Jetty)
- 2 years of continuous work at portal www.abclinuxu.cz
- project design
- (re)implementation of CSS 2.1 parser concerning easy update as
specification of CSS evolves http://cssbox.sourceforge.net/jstyleparser/
- team implementation of XML database on scratch with client-server SSL
access with JSP frontend sample application, abstract availablee at
http://www.esiee.fr/~bureaud/Unites/Pr302i/0607/i307et05.pdf
- ability to connect different pieces of code and/or software
flawlessly - bachelor thesis, comparison of Wikipedia portals based on
Apache Coocon with XML database exist and Stripes with 'Wicket' like
extension and PostgreSQL
I would like have more information what I will be supposed to do.
For example, it would be great if code is done with concerning JSR-286
forward compatibility.
Thank in advance for response
Karel Piwko
Hai Ludovic,Serigue and Other GSOC ppl
I had upload the functional view of the survey. Click here
<http://www.xwiki.org/xwiki/bin/view/XWiki/ChathuraPrabuddha>to view it.
Plan to add the architecture diagram in next fix few days.
Hope that this will be helpfull to other gsoccers too..
Mean while I had uploaded my application to the gsoc site.
Also I mailled the pdf it to Asiri and Ludovic.
So dear mentors please send me your kind feedback about my application.
good luck
Hi,
I need some help locating the code for Google Gadgets (
http://incubator.myxwiki.org/xwiki/bin/view/Gadgets/). I don't see it in
platform/xwiki-applications or platform/xwiki-plugins (in
http://svn.xwiki.org/svnroot/xwiki/).
Also what is it : an application, plugin, component ? (combination of them?)
Is it implemented as a container that supports the original gadgets API. How
about the Open Social API ? (as the project specifies, they should both be
implemented)
I think it would be nice to allow users to add gadgets/open social gadgets
to the sidebar as well, not only on the Dashboard page. What do you think ?
Thanks,
Anamaria
Hi,
I've finished the annotation implementation for registering
components. The rendering modules have been migrated to annotations
fully so I believe it's now strong enough to be used globally in XWiki.
I'd like to propose that we use annotations for all new code from now
on and slowly refactor existing code to use them.
Here's my +1
Thanks
-Vincent
Hi,
So far we've been using plexus configuration mechanism in
components.xml to define component configuration data. I'm proposing
to drop this. Reasons:
1) This is trying us to plexus and is not generic enough for all IOC
frameworks
2) It doesn't easily allow overriding config values (for ex if the
user wants to override a value in a wiki page or in xwiki.properties
file)
I thus propose 3 things:
1) to use our new xwiki configuration mechanism to store component
configuration data
2) to have a META-INF/<module prefix>.properties file located in the
module jar where <module prefix> is org.xwiki.rendering for example
for the rendering module (we could also have a submodule if the module
is split into several modules). The idea is that the file name needs
to be unique across jars so that we can create uberjars later on if
need be.
3) in general we shouldn't have component-specific config data and
instead make the data as generic config data as much as possible and
bound to the module's Configuration component instead.
For 1) and 2), it's very easy to do:
- the component which requires config data need to have
ConfigurationManager and ConfigurationSources injected and implement
the Initializable interface and then call in initialize():
this.configurationManager.initializeConfiguration(this,
this.sourceCollection.getConfigurationSources(), <prefix>);
- store data using a FQN in META-INF/<module prefix>.properties, for
example:
org.xwiki.rendering.internal.macro.RealmMacroSource.priority = 10
In this example you would call initializeConfiguration with a prefix
value of RealmMacroSource.getClass().getName().
3) is important because otherwise users will be able to override
private config data and if the internal implementation changes the
config data won't be valid anymore. The reason for 2) is to hide these
config data from the users as much as possible since these are
advanced config options that shouldn't normally be used.
For example we would defined a default priority for macros but in some
very exceptional cases the user would want to change the priority so
that the macro executes at a different time for a given reason.
Another example if the velocity components which contain lots of data.
I believe these data should be moved to a VelocityConfiguration
component instead.
WDYT?
Thanks
-Vincent
Hi,
My name is Dhaval Shah. I am pursuing my Master's in Computer Science at San Jose State University.
This
semester, I have taken a subject named Open Software Development. I
want to perform one project in it. I am interested to work on i3sp
project.
Can you please give me some suggestions about the
current enhancement required for the project? I am eagerly waiting for
your reply.
Thank you.
Sincerely,
Dhaval Shah
Hi devs,
I need some help to decide what is the best to convert objects when
changing the syntax.
The problem is that we can't just extend the content conversion
javascript to the objects because the way edit mode works the
wiki/WYSIWYG and objects edit modes are isolated: the page is reloaded
and content lost when switching to objects are reloaded for database.
So I can see some way to do some more clean that others:
1) refactor the general edit mode to load everything and switch
between content/objects without reloading the page or at least without
loosing content like we do for WYSIWYG/content switch
2) let the content conversion work as it is and convert and save the objects
3) convert and save everything
I think 1) would be the best, I think the user should not loose
content when switching objects/content anyway. But this looks like too
big for 1.8.1 which need the objects converted when content is
converted.
2) is wrong IMO because this mean we will have a 2.0 document with 1.0
content/2.0 objects in it until the user save the document and worst
if the user does not save the content.
I think we should do 3) (with a warning to the user saying that this
change can be reverted in the history) waiting for 1).
WDYT ?
--
Thomas Mortagne
Hi,
Yesterday I have successfully build XWiki from command line and load its
core platform to eclipse. And I am working with Ubuntu Linux and my
environment is all set up with XWiki development tools now and from today
night onwards it would be great to start some sort of development. I have to
study some tutorials to get familiar with the platform more.
Question on Jabber integration
Please help me on deciding this.
Regarding my development, should I have to come up with a component that
integrates to XWiki Enterprise that will provide Jabber integration with
XWiki Enterprise? or should it integrate with XWiki platform directly ?. I
am still learning XWiki and sometimes this could be a bad question here. I
think once I get done with the tutorials it would be fine. Please give your
valuable idea on this to select and work in a specific module. It would be
really helpful for me to use my time much effectively with XWiki.
Thank you,
*H.T.M. Gamage **
*Student,* *
Faculty of Information Technology,
University of Moratuwa,
SriLanka.
Mobile: +94 (71) 5518852
Blog : tharindufit.wordpress.com