1 Apr
2012
1 Apr
'12
5:24 p.m.
Hi all,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I created a proposal for the Google Android XWiki Connector.
link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf
(failed to attach it to the mail and send as the mail bounced back alerting
the file is too big. : 603KB)
Thank you.
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <sasindarukshan(a)gmail.com>wrote;wrote:
Hi,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I have attached here with a proposal for the Google Android XWiki
Connector.
Thank You.
Sasinda Rukshan.
1 Apr
1 Apr
8:08 p.m.
New subject: [xwiki-devs] GSoC 2012
Hi Sasinda,
Glad to ear that you are interested in this project.
I just read your proposal and I must say I like a lot the Approach 1
since the heart of the project for me is to make easy for others to
build well integrated Android applications which need to manipulate
XWiki datas. Applications built by us on top of it have mostly
example/demo value for me.
What you described is very complete and indeed probably a bit too much
for the GSOC, but it would be good IMO to do something between the two
approach. While the full framework is probably a bit too much in the
time frame, only doing an application and not improve and extends the
current framework would not be the best direction I think.
An idea would be to lead the way to the framework you described and
implement only the part needed for your blog application idea or
another application the same way the previous GSOC built the current
connector as a dependency of a demo XWiki client.
On Sun, Apr 1, 2012 at 5:24 PM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
Hi all,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I created a proposal for the Google Android XWiki Connector.
link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf
(failed to attach it to the mail and send as the mail bounced back alerting
the file is too big. : 603KB)
Thank you.
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <sasindarukshan(a)gmail.com>wrote;wrote:
--
Thomas Mortagne
Hi,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I have attached here with a proposal for the Google Android XWiki
Connector.
Thank You.
Sasinda Rukshan.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2 Apr
2 Apr
5:20 a.m.
New subject: [xwiki-devs] GSoC 2012
Hi Thomas,
I am very happy to here that you like my approach.Thanks. I was discouraged
to do approach 1 not only because it would take a bit more time and effort.
It was mainly because if I am doing such a framework future developers will
be depending on my framework, so if I do a, say not that good job I will be
making there time rough with a bad base framework. The only workaround I
see is we must talk with some experienced architects in the community and
come up with a good and salable base framework that provides simple and
intuitive APIs so that the usage of the framework will have a short
learning curve. In my opinion it does not take much effort to start making
a fully functional complex API.The case is the early developers that move
in to develop the framework will do a good job but later the framework will
become complex and they will be doing workarounds to present more
functionality from the framework making architecture degradation of the
framework. It takes a lot more effort and thought to make a fully
functional simple API(Which hides its complexity from the developers) and
make it scalable with the simplicity intact. It is not possible to come up
with the design of such a framework at once, we would have to re
architecture it at major versions. But it is important to keep the earlier
point in mind.
I like to have a scalable and simple framework that follows consistent
patterns so later developers who scale up the base framework will have a
clearly defined scheme to scale it up, and will avoid add hoc manners of
doing it.
I really love to do this, so the developers who join us later will praise
us for doing such a well structured framework which is easy to build on top
of it and easy to scale from the inside.
If I am to do this, We can do some research on other application frameworks
and come up with a good initial design for our framework in the community
bonding period (After 10 th May. I am having semester end exams till that.
And I will be very much free being an intern after that.Internship is said
to be far less work than what you go through in a semester). Your base
connection framework is superb. We would let that foundation framework be
considered only about the connection aspects (providing APIs for REST WS or
RPC). We will consider how the rest of the framework is built on top of it
(approach 1 was only an initial idea there wasn't much thought behind it).
This semester I am taking up an optional course for software architecture,
I ll make sure to study well for it. I apologize if I am not replying you
soon enough.
Thank you.
Regards,
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 11:38 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi Sasinda,
Glad to ear that you are interested in this project.
I just read your proposal and I must say I like a lot the Approach 1
since the heart of the project for me is to make easy for others to
build well integrated Android applications which need to manipulate
XWiki datas. Applications built by us on top of it have mostly
example/demo value for me.
What you described is very complete and indeed probably a bit too much
for the GSOC, but it would be good IMO to do something between the two
approach. While the full framework is probably a bit too much in the
time frame, only doing an application and not improve and extends the
current framework would not be the best direction I think.
An idea would be to lead the way to the framework you described and
implement only the part needed for your blog application idea or
another application the same way the previous GSOC built the current
connector as a dependency of a demo XWiki client.
On Sun, Apr 1, 2012 at 5:24 PM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi all,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I created a proposal for the Google Android XWiki Connector.
link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf
(failed to attach it to the mail and send as the mail bounced back
alerting
the file is too big. : 603KB)
Thank you.
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <
sasindarukshan(a)gmail.com>wroteote:
Hi,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I have attached here with a proposal for the Google Android XWiki
Connector.
Thank You.
Sasinda Rukshan.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:18 a.m.
New subject: [xwiki-devs] GSoC 2012
I agree that it's impossible to do a perfect framework like that at
once, that's why it's important to do it peace by peace and properly
separate subjects and abstraction levels from the start. Now we have
to start somewhere and in my opinion it's OK to refactor and
deprecated stuff it as soon as something is starting to be too
complex. The "advantage" with Android is that libraries can't really
be shared (not yet at least) so it's not a big issue to break some
APIs as long as you always provide alternatives since each version of
the library is bundled with each application that is using it.
On Mon, Apr 2, 2012 at 5:20 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
Hi Thomas,
I am very happy to here that you like my approach.Thanks. I was discouraged
to do approach 1 not only because it would take a bit more time and effort.
It was mainly because if I am doing such a framework future developers will
be depending on my framework, so if I do a, say not that good job I will be
making there time rough with a bad base framework. The only workaround I
see is we must talk with some experienced architects in the community and
come up with a good and salable base framework that provides simple and
intuitive APIs so that the usage of the framework will have a short
learning curve. In my opinion it does not take much effort to start making
a fully functional complex API.The case is the early developers that move
in to develop the framework will do a good job but later the framework will
become complex and they will be doing workarounds to present more
functionality from the framework making architecture degradation of the
framework. It takes a lot more effort and thought to make a fully
functional simple API(Which hides its complexity from the developers) and
make it scalable with the simplicity intact. It is not possible to come up
with the design of such a framework at once, we would have to re
architecture it at major versions. But it is important to keep the earlier
point in mind.
I like to have a scalable and simple framework that follows consistent
patterns so later developers who scale up the base framework will have a
clearly defined scheme to scale it up, and will avoid add hoc manners of
doing it.
I really love to do this, so the developers who join us later will praise
us for doing such a well structured framework which is easy to build on top
of it and easy to scale from the inside.
If I am to do this, We can do some research on other application frameworks
and come up with a good initial design for our framework in the community
bonding period (After 10 th May. I am having semester end exams till that.
And I will be very much free being an intern after that.Internship is said
to be far less work than what you go through in a semester). Your base
connection framework is superb. We would let that foundation framework be
considered only about the connection aspects (providing APIs for REST WS or
RPC). We will consider how the rest of the framework is built on top of it
(approach 1 was only an initial idea there wasn't much thought behind it).
This semester I am taking up an optional course for software architecture,
I ll make sure to study well for it. I apologize if I am not replying you
soon enough.
Thank you.
Regards,
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 11:38 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
Hi Sasinda,
Glad to ear that you are interested in this project.
I just read your proposal and I must say I like a lot the Approach 1
since the heart of the project for me is to make easy for others to
build well integrated Android applications which need to manipulate
XWiki datas. Applications built by us on top of it have mostly
example/demo value for me.
What you described is very complete and indeed probably a bit too much
for the GSOC, but it would be good IMO to do something between the two
approach. While the full framework is probably a bit too much in the
time frame, only doing an application and not improve and extends the
current framework would not be the best direction I think.
An idea would be to lead the way to the framework you described and
implement only the part needed for your blog application idea or
another application the same way the previous GSOC built the current
connector as a dependency of a demo XWiki client.
On Sun, Apr 1, 2012 at 5:24 PM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
--
Thomas Mortagne
_______________________________________________
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 Hi all,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I created a proposal for the Google Android XWiki Connector.
link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf
(failed to attach it to the mail and send as the mail bounced back
alerting
the file is too big. : 603KB)
Thank you.
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <
sasindarukshan(a)gmail.com>wroteote:
Hi,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I have attached here with a proposal for the Google Android XWiki
Connector.
Thank You.
Sasinda Rukshan.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:55 a.m.
New subject: [xwiki-devs] GSoC 2012
Hi Thomas,
Thanks for the advice.
Shall I remake a proposal with the approach you suggested? Or should we
discuss furthermore how it should be done?
Am I correct to assume we are now focusing mainly on the framework and the
applications will be just demos as previous time.
In the 1st proposal I was thinking of a main application that you can
plugin other parts such as bloggers and navigators... etc. All the
user/settings entered through the Settings of the main app can be shared
through the plugin apps.
If we are going to separate apps, settings data can be shared by the
database, Android Content providers or any other means android allows for
sharing of data. I am not yet technically efficient in Android to
specifically say what is better. Then other applications can set the
default settings,or override with app specific settings , where default
ones are shared among all apps. (another approach would be to have
a separate app to manage settings)
Does the proposal need that much of detail in it? Will my earlier proposal
suffice with the two ends moderated?.
Regards,
Sasinda Rukshan.
On Mon, Apr 2, 2012 at 11:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
I agree that it's impossible to do a perfect
framework like that at
once, that's why it's important to do it peace by peace and properly
separate subjects and abstraction levels from the start. Now we have
to start somewhere and in my opinion it's OK to refactor and
deprecated stuff it as soon as something is starting to be too
complex. The "advantage" with Android is that libraries can't really
be shared (not yet at least) so it's not a big issue to break some
APIs as long as you always provide alternatives since each version of
the library is bundled with each application that is using it.
On Mon, Apr 2, 2012 at 5:20 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
Hi Thomas,
I am very happy to here that you like my approach.Thanks. I was
discouraged
to do approach 1 not only because it would take a
bit more time and
effort.
It was mainly because if I am doing such a
framework future developers
will
be depending on my framework, so if I do a, say
not that good job I will
be
making there time rough with a bad base
framework. The only workaround I
see is we must talk with some experienced architects in the community and
come up with a good and salable base framework that provides simple and
intuitive APIs so that the usage of the framework will have a short
learning curve. In my opinion it does not take much effort to start
making
a fully functional complex API.The case is the
early developers that move
in to develop the framework will do a good job but later the framework
will
become complex and they will be doing workarounds
to present more
functionality from the framework making architecture degradation of the
framework. It takes a lot more effort and thought to make a fully
functional simple API(Which hides its complexity from the developers) and
make it scalable with the simplicity intact. It is not possible to come
up
with the design of such a framework at once, we
would have to re
architecture it at major versions. But it is important to keep the
earlier
point in mind.
I like to have a scalable and simple framework that follows consistent
patterns so later developers who scale up the base framework will have a
clearly defined scheme to scale it up, and will avoid add hoc manners of
doing it.
I really love to do this, so the developers who join us later will praise
us for doing such a well structured framework which is easy to build on
top
of it and easy to scale from the inside.
If I am to do this, We can do some research on other application
frameworks
and come up with a good initial design for our
framework in the community
bonding period (After 10 th May. I am having semester end exams till
that.
And I will be very much free being an intern
after that.Internship is
said
to be far less work than what you go through in a
semester). Your base
connection framework is superb. We would let that foundation framework be
considered only about the connection aspects (providing APIs for REST WS
or
RPC). We will consider how the rest of the
framework is built on top of
it
(approach 1 was only an initial idea there
wasn't much thought behind
it).
This semester I am taking up an optional course
for software
architecture,
I ll make sure to study well for it. I apologize
if I am not replying you
soon enough.
Thank you.
Regards,
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 11:38 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Sasinda,
Glad to ear that you are interested in this project.
I just read your proposal and I must say I like a lot the Approach 1
since the heart of the project for me is to make easy for others to
build well integrated Android applications which need to manipulate
XWiki datas. Applications built by us on top of it have mostly
example/demo value for me.
What you described is very complete and indeed probably a bit too much
for the GSOC, but it would be good IMO to do something between the two
approach. While the full framework is probably a bit too much in the
time frame, only doing an application and not improve and extends the
current framework would not be the best direction I think.
An idea would be to lead the way to the framework you described and
implement only the part needed for your blog application idea or
another application the same way the previous GSOC built the current
connector as a dependency of a demo XWiki client.
On Sun, Apr 1, 2012 at 5:24 PM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi all,
I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
I created a proposal for the Google Android XWiki Connector.
link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf
(failed to attach it to the mail and send as the mail bounced back
alerting
the file is too big. : 603KB)
Thank you.
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <
sasindarukshan(a)gmail.com>wroteote:
> Hi,
>
> I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
> I have attached here with a proposal for the Google Android XWiki
> Connector.
>
> Thank You.
>
> Sasinda Rukshan.
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:44 a.m.
New subject: [xwiki-devs] GSoC 2012
On Mon, Apr 2, 2012 at 10:55 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
Hi Thomas,
Thanks for the advice.
Shall I remake a proposal with the approach you suggested? Or should we
discuss furthermore how it should be done?
Am I correct to assume we are now focusing mainly on the framework and the
applications will be just demos as previous time.
In the 1st proposal I was thinking of a main application that you can
plugin other parts such as bloggers and navigators... etc. All the
user/settings entered through the Settings of the main app can be shared
through the plugin apps.
If we are going to separate apps, settings data can be shared by the
database, Android Content providers or any other means android allows for
sharing of data. I am not yet technically efficient in Android to
specifically say what is better. Then other applications can set the
default settings,or override with app specific settings , where default
ones are shared among all apps. (another approach would be to have
a separate app to manage settings)
Not an Android expert either but at least it would be nice to have
XWiki account listed as Android account and make them the standard way
for an application to connect to an XWiki instance (unless the
application use its own settings for some reason). The problem with
having an application dedicated to managing setting for others is that
you can't really indicate dependencies between applications on Android
so that means the framework should know a commons place to store
thoses settings, I don't know in details how Android account in
setting are working but sounds like a good place for this.
It's not that much that we plan to do ourself separate applications
but for me the main target is to allow any application to easily
communicate with an XWiki instance for whatever reason and even better
if we don't code the application ourself, the goal is to make people
use XWiki ;) The framework you described in general is still valid as
a set of consistent libraries arround XWiki as I always seen it
myself.
The idea of an XWiki centric application with plugins is however still
a good idea as platform to show off what the framework allows to do.
Does the proposal need that much of detail in it? Will
my earlier proposal
suffice with the two ends moderated?.
No need to details too much but indicating if and how you plan to
allow applications to share settings, local cache when offline, etc.
is important I think.
You should directly write your proposal on melange since we now agree
with the general idea (you can modify the details anytime you want).
IMO a good practice given the short time is to describe the target
demo application you plan to do (for example the blog) and make
everything needed for this demo a reusable set a well defined and
tested tools that would allow anyone to redo the same thing without
much custom code like it has been done for what's currently in
https://github.com/xwiki-contrib/android-client.
Regards,
Sasinda Rukshan.
On Mon, Apr 2, 2012 at 11:48 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
I agree that it's impossible to do a perfect
framework like that at
once, that's why it's important to do it peace by peace and properly
separate subjects and abstraction levels from the start. Now we have
to start somewhere and in my opinion it's OK to refactor and
deprecated stuff it as soon as something is starting to be too
complex. The "advantage" with Android is that libraries can't really
be shared (not yet at least) so it's not a big issue to break some
APIs as long as you always provide alternatives since each version of
the library is bundled with each application that is using it.
On Mon, Apr 2, 2012 at 5:20 AM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Thomas,
I am very happy to here that you like my approach.Thanks. I was
discouraged
to do approach 1 not only because it would take a
bit more time and
effort.
It was mainly because if I am doing such a
framework future developers
will
be depending on my framework, so if I do a, say
not that good job I will
be
making there time rough with a bad base
framework. The only workaround I
see is we must talk with some experienced architects in the community and
come up with a good and salable base framework that provides simple and
intuitive APIs so that the usage of the framework will have a short
learning curve. In my opinion it does not take much effort to start
making
a fully functional complex API.The case is the
early developers that move
in to develop the framework will do a good job but later the framework
will
become complex and they will be doing workarounds
to present more
functionality from the framework making architecture degradation of the
framework. It takes a lot more effort and thought to make a fully
functional simple API(Which hides its complexity from the developers) and
make it scalable with the simplicity intact. It is not possible to come
up
with the design of such a framework at once, we
would have to re
architecture it at major versions. But it is important to keep the
earlier
point in mind.
I like to have a scalable and simple framework that follows consistent
patterns so later developers who scale up the base framework will have a
clearly defined scheme to scale it up, and will avoid add hoc manners of
doing it.
I really love to do this, so the developers who join us later will praise
us for doing such a well structured framework which is easy to build on
top
of it and easy to scale from the inside.
If I am to do this, We can do some research on other application
frameworks
and come up with a good initial design for our
framework in the community
bonding period (After 10 th May. I am having semester end exams till
that.
And I will be very much free being an intern
after that.Internship is
said
to be far less work than what you go through in a
semester). Your base
connection framework is superb. We would let that foundation framework be
considered only about the connection aspects (providing APIs for REST WS
or
RPC). We will consider how the rest of the
framework is built on top of
it
(approach 1 was only an initial idea there
wasn't much thought behind
it).
This semester I am taking up an optional course
for software
architecture,
I ll make sure to study well for it. I apologize
if I am not replying you
soon enough.
Thank you.
Regards,
Sasinda Rukshan.
On Sun, Apr 1, 2012 at 11:38 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Sasinda,
Glad to ear that you are interested in this project.
I just read your proposal and I must say I like a lot the Approach 1
since the heart of the project for me is to make easy for others to
build well integrated Android applications which need to manipulate
XWiki datas. Applications built by us on top of it have mostly
example/demo value for me.
What you described is very complete and indeed probably a bit too much
for the GSOC, but it would be good IMO to do something between the two
approach. While the full framework is probably a bit too much in the
time frame, only doing an application and not improve and extends the
current framework would not be the best direction I think.
An idea would be to lead the way to the framework you described and
implement only the part needed for your blog application idea or
another application the same way the previous GSOC built the current
connector as a dependency of a demo XWiki client.
On Sun, Apr 1, 2012 at 5:24 PM, sasinda rukshan
<sasindarukshan(a)gmail.com> wrote:
> Hi all,
> I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
> I created a proposal for the Google Android XWiki Connector.
> link : http://dl.dropbox.com/u/30342197/x%20wiki.pdf
> (failed to attach it to the mail and send as the mail bounced back
alerting
> the file is too big. : 603KB)
>
> Thank you.
> Sasinda Rukshan.
>
> On Sun, Apr 1, 2012 at 2:55 PM, sasinda rukshan <
sasindarukshan(a)gmail.com>wroteote:
>
>> Hi,
>>
>> I am Sasinda Rukshan from University of Moratuwa Sri Lanka.
>> I have attached here with a proposal for the Google Android XWiki
>> Connector.
>>
>> Thank You.
>>
>> Sasinda Rukshan.
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
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
4603
days inactive
4604
days old
5 comments
2 participants
participants (2)
-
sasinda rukshan -
Thomas Mortagne