Hello Gregor and all, Thank you very much. Apology for not responding quickly. I was out of town for a few days and just got back.
Most ideas in the proposal come from your previous discussions, and surely I'd love to have more of your inputs, as early as possible. This and the next week is listed in my proposal as pooling the Lenya developers' for requirements. It would be nice to give me any ideas within this time slot. As Gregor suggested, I should compile a spec before mid July. After that I shall focus on implementation and leave the late ideas for the next version. Thanks Michi for the OSR 101 idea. I agree that it doesn't make much sense if the APIs are not as general as possible to accommodate most editors. A Lenya specific APIs won't work. Very few editors would actually implement them. It's the "Mohammed and the mountain" problem, and I think Lenya will have to be the side that takes initiation. However the question remains that if an editor does not support certain things shall we just leave it and lose certain functionality, e.g., from tightly integration with Lenya to loosely integration, or simply an external editor that does editing job only but cannot access assets and links managed by Apache Lenya? This may sound absurd in the first sight but if the tightly coupled editor cannot do certain things an external editor can do, isn't it better to be able to do it awkwardly rather than cannot do it at all? At this stage I have almost no idea how Lenya works so the above question is only speculation. Let me know what you think. Zhiwu Monday, June 27, 2005, 2:22:17 PM, you wrote: GJR> As most people here will know Google are running a "Summer of Code" GJR> program - see code.google.com. The idea is that Google pay 410 students GJR> to work on an Open Source project over the summer. The OS project must GJR> provide a mentor to help the student find their feet quickly and to GJR> support the student through the project. GJR> Apache received over 870 projects and were given 38 awards by Google. GJR> These students applications have been reviewed by Apache and the 38 GJR> students have been selected. GJR> Apache Lenya accepted 2 proposals, the search proposal by Robert Goene GJR> and the editors proposal by Zhiwu Xie. GJR> So, I would like to welcome Zhiwu Xie to the Apache Lenya community. GJR> Zhiwu is to be treated like any other developer, the only real GJR> difference I have a responsibility to assist in him learning the "Apache GJR> Way". All design discussion will be carried out in the normal way and GJR> Zhiwu (and Robert too) will receive SVN commit rights to a special GJR> branch within Lenya, to be determined. GJR> Zhiwu, please note that there will be a gathering of committers at GJR> Apachecon Europe 7/18-7/22, and we do intend to talk about the editor GJR> api proposal face 2 face at that time. it would be good if you could get GJR> your API definition ready for that date (your week 5), so that we can GJR> review in a high throughput environment. GJR> Again, welcome! GJR> -gregor GJR> Editor Plug-in APIs for Lenya GJR> ============================= GJR> by Zhiwu Xie GJR> [EMAIL PROTECTED] GJR> Synopsis GJR> -------- GJR> This project will investigate and implement the editor plug-in APIs for GJR> Lenya, an open source Java/XML Content Management System. GJR> Benefits GJR> -------- GJR> The proposed Lenya editor plug-in APIs will: GJR> - Enable the ability to readily plug in different editors to Lenya GJR> - Free the Lenya developers from maintaining multiple editors shipped GJR> with Lenya GJR> - Enable the functionality evolving with upgrades of different editors. GJR> - Enhance the Lenya usability by allowing users to use the editors of GJR> their choice. GJR> Deliverables GJR> ------------ GJR> - Editor plug-in APIs for Lenya GJR> - Implement plug-ins for BXE and/or Kupo to demonstrate the GJR> applicability of the API approach GJR> Project Details GJR> --------------- GJR> Although currently shipped with two open source editing packages BXE and GJR> Kupo, Lenya is still in need of an editor that can fully meet the GJR> ever-growing requirements for different content management use cases. GJR> Some of the requirements identified by the Lenya developers are: GJR> - Multiple browsers compatibility including IE and Mozilla GJR> - Can edit XML, XHTML, and HTML GJR> - Blog publication support GJR> This list is expected to grow longer with the time, but none of the GJR> included editors can meet even the basic requirements listed above. GJR> A naive solution to the problem can be extending either BXE or Kupo, or GJR> another editor that shows better prospect to meet our requirements. But GJR> a closer analysis reveals its limitations: GJR> - The current Lenya editor integration method, or the lack of it, is GJR> very time and resource consuming to upgrade and maintain, therefore is GJR> not sustainable for an open source project like this. Concerns have been GJR> raised by Lenya developers that "we are too short on energy and GJR> developers to support this many editors". GJR> - Which editor shall we choose to support? They all have strengths and GJR> shortcomings. Even if we can make the best choice for now, how can we be GJR> so sure about the future? What if the chosen editor is dated in a year GJR> yet no subsequent development will be scheduled? GJR> - After all Lenya is about content management, not content editing. Is GJR> it worthwhile to put so much effort in editor development? GJR> - Large numbers of editors are widely available for various purposes. GJR> Even though none of them can be identified to meet all Lenya's GJR> requirements, put together as a whole they can, and should remain so GJR> with their own evolvements and upgrades. There is no need to re-invent GJR> the wheel. GJR> Apparently, finding a way to mount the wheels is a smarter solution. The GJR> proposed Lenya editor plug-in APIs will take this approach and solve the GJR> problem by providing clearly defined interfaces for an editor software GJR> to be plugged into Lenya. The problem can therefore be well managed by GJR> defining contracts or interfaces between Lenya and the editors Lenya GJR> uses, with Lenya as the client that requests services from the GJR> interfaces, and various editors as the servers that provide the services GJR> required. GJR> We make no assumption on which editors can be used. They can be either GJR> browser based editors or standalone applications, open source or GJR> commercial software. The only requirement is that for an editor to be GJR> plugged in, it must provide implementations to these APIs. GJR> In order for Lenya to smartly choose the editor for a specific purpose, GJR> the proposed APIs should also "provide a way to tell the Lenya core what GJR> documents can be edited and what it takes". By doing so, when an editor GJR> plug-in is available and shows it can edit a certain kind of document, GJR> if invoking the editor the functionalities should be readily working GJR> without further twists. GJR> The proposed API will be implemented with the same tools used for Lenya GJR> development. The applicant will work closely with Lenya developers, GJR> especially the mentors to ensure the project's usefulness to Lenya. GJR> Project Schedule GJR> ---------------- GJR> Total development period will be 8 weeks from 24 June 2005 to 20 August GJR> 2005. A breakdown of the schedule is as following: GJR> - Week 1 and 2: Inception. Review and if required, study programming GJR> skills and tools. Set up the development environment. Lenya editor GJR> requirements gathering and analysis by pooling and requesting comments GJR> from Lenya developers. GJR> - Week 3 and 4: Study Lenya source code. Continue consolidate the API GJR> requirements. API analysis. GJR> - Week 5: API definition GJR> - Week 6 and 7: Plug-in implementation for either BXE and/or Kupo. GJR> - Week 8: Remaining debugging. Testing, documentation, and review. GJR> Biography GJR> --------- GJR> I'm currently a 2nd year PhD student of computer engineering in GJR> University of New Mexico. My PhD research is on digital library, a GJR> closely related topic to content management and Lenya, and I plan to GJR> extensively use Apache?s Java/XML packages in my research. My technical GJR> background includes high performance computing, OO software development, GJR> and requirements engineering. I have programmed with C/C++, java, and GJR> Matlab, developed algorithms and simulation packages as well as designed GJR> and implemented University of New Mexico Libraries' eResource Management GJR> System, a LAMP based web application. The Lenya editor plug-in API GJR> project will introduce me to the open source software development, to GJR> which I look forward to contributing more in my future career. GJR> Reference GJR> --------- GJR> ProposalEditors. http://wiki.apache.org/lenya/ProposalEditors --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
