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 <[email protected]> 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 > <[email protected]>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 >> <[email protected]> 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 < >> [email protected]>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. >> >> >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
