You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by "Gregor J. Rothfuss" <gr...@apache.org> on 2005/06/27 22:22:17 UTC
welcome to summer of code, Zhiwu Xie!
As most people here will know Google are running a "Summer of Code"
program - see code.google.com. The idea is that Google pay 410 students
to work on an Open Source project over the summer. The OS project must
provide a mentor to help the student find their feet quickly and to
support the student through the project.
Apache received over 870 projects and were given 38 awards by Google.
These students applications have been reviewed by Apache and the 38
students have been selected.
Apache Lenya accepted 2 proposals, the search proposal by Robert Goene
and the editors proposal by Zhiwu Xie.
So, I would like to welcome Zhiwu Xie to the Apache Lenya community.
Zhiwu is to be treated like any other developer, the only real
difference I have a responsibility to assist in him learning the "Apache
Way". All design discussion will be carried out in the normal way and
Zhiwu (and Robert too) will receive SVN commit rights to a special
branch within Lenya, to be determined.
Zhiwu, please note that there will be a gathering of committers at
Apachecon Europe 7/18-7/22, and we do intend to talk about the editor
api proposal face 2 face at that time. it would be good if you could get
your API definition ready for that date (your week 5), so that we can
review in a high throughput environment.
Again, welcome!
-gregor
Editor Plug-in APIs for Lenya
=============================
by Zhiwu Xie
zxie@ece.unm.edu
Synopsis
--------
This project will investigate and implement the editor plug-in APIs for
Lenya, an open source Java/XML Content Management System.
Benefits
--------
The proposed Lenya editor plug-in APIs will:
- Enable the ability to readily plug in different editors to Lenya
- Free the Lenya developers from maintaining multiple editors shipped
with Lenya
- Enable the functionality evolving with upgrades of different editors.
- Enhance the Lenya usability by allowing users to use the editors of
their choice.
Deliverables
------------
- Editor plug-in APIs for Lenya
- Implement plug-ins for BXE and/or Kupo to demonstrate the
applicability of the API approach
Project Details
---------------
Although currently shipped with two open source editing packages BXE and
Kupo, Lenya is still in need of an editor that can fully meet the
ever-growing requirements for different content management use cases.
Some of the requirements identified by the Lenya developers are:
- Multiple browsers compatibility including IE and Mozilla
- Can edit XML, XHTML, and HTML
- Blog publication support
This list is expected to grow longer with the time, but none of the
included editors can meet even the basic requirements listed above.
A naive solution to the problem can be extending either BXE or Kupo, or
another editor that shows better prospect to meet our requirements. But
a closer analysis reveals its limitations:
- The current Lenya editor integration method, or the lack of it, is
very time and resource consuming to upgrade and maintain, therefore is
not sustainable for an open source project like this. Concerns have been
raised by Lenya developers that "we are too short on energy and
developers to support this many editors".
- Which editor shall we choose to support? They all have strengths and
shortcomings. Even if we can make the best choice for now, how can we be
so sure about the future? What if the chosen editor is dated in a year
yet no subsequent development will be scheduled?
- After all Lenya is about content management, not content editing. Is
it worthwhile to put so much effort in editor development?
- Large numbers of editors are widely available for various purposes.
Even though none of them can be identified to meet all Lenya's
requirements, put together as a whole they can, and should remain so
with their own evolvements and upgrades. There is no need to re-invent
the wheel.
Apparently, finding a way to mount the wheels is a smarter solution. The
proposed Lenya editor plug-in APIs will take this approach and solve the
problem by providing clearly defined interfaces for an editor software
to be plugged into Lenya. The problem can therefore be well managed by
defining contracts or interfaces between Lenya and the editors Lenya
uses, with Lenya as the client that requests services from the
interfaces, and various editors as the servers that provide the services
required.
We make no assumption on which editors can be used. They can be either
browser based editors or standalone applications, open source or
commercial software. The only requirement is that for an editor to be
plugged in, it must provide implementations to these APIs.
In order for Lenya to smartly choose the editor for a specific purpose,
the proposed APIs should also "provide a way to tell the Lenya core what
documents can be edited and what it takes". By doing so, when an editor
plug-in is available and shows it can edit a certain kind of document,
if invoking the editor the functionalities should be readily working
without further twists.
The proposed API will be implemented with the same tools used for Lenya
development. The applicant will work closely with Lenya developers,
especially the mentors to ensure the project's usefulness to Lenya.
Project Schedule
----------------
Total development period will be 8 weeks from 24 June 2005 to 20 August
2005. A breakdown of the schedule is as following:
- Week 1 and 2: Inception. Review and if required, study programming
skills and tools. Set up the development environment. Lenya editor
requirements gathering and analysis by pooling and requesting comments
from Lenya developers.
- Week 3 and 4: Study Lenya source code. Continue consolidate the API
requirements. API analysis.
- Week 5: API definition
- Week 6 and 7: Plug-in implementation for either BXE and/or Kupo.
- Week 8: Remaining debugging. Testing, documentation, and review.
Biography
---------
I'm currently a 2nd year PhD student of computer engineering in
University of New Mexico. My PhD research is on digital library, a
closely related topic to content management and Lenya, and I plan to
extensively use Apache�s Java/XML packages in my research. My technical
background includes high performance computing, OO software development,
and requirements engineering. I have programmed with C/C++, java, and
Matlab, developed algorithms and simulation packages as well as designed
and implemented University of New Mexico Libraries' eResource Management
System, a LAMP based web application. The Lenya editor plug-in API
project will introduce me to the open source software development, to
which I look forward to contributing more in my future career.
Reference
---------
ProposalEditors. http://wiki.apache.org/lenya/ProposalEditors
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Doug Chestnut wrote:
>>
>> But WebDAV is just not sufficient for this purpose.
>
>
> I agree that WebDAV isn't sufficient for all of the required cms
> actions, but I think it could be a starting point. Extend it for the
> features that it doesn't provide. It would at least take care of
> Level 1 compliance. Just my two cents :)
yes, for instance
>>
>> I think this depends very much on what the existing site is based.
>
>
> Dreamweaver template based. Currently using dreamweaver to
> restructure [including renaming files] my site to fit into Lenya
> default based publication [dreamweaver fixes links as you move things
> around].
sounds very interesting. Could you provide a sample publication to show
how this really works? I guess you have one ;-)
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Doug Chestnut <dh...@virginia.edu>.
Michael Wechner wrote:
> Doug Chestnut wrote:
>
>> I like the webDAV approach because one can use it with so many
>> different editors. Most desktop web editors support webDAV and have
>> for a while. If the editor doesn't support webDAV, well, just make a
>> web folder (windows) or mount_webdav (mac, which doesn't work yet,
>> think it doesn't like the way the depth header isn't respected
>> currently).
>
> as mentioned in my email to Gregor, OSR-101 is not about editing only,
> whereas
> it's a minor part in it, but a good topic to start with.
>
> But WebDAV is just not sufficient for this purpose.
I agree that WebDAV isn't sufficient for all of the required cms
actions, but I think it could be a starting point. Extend it for the
features that it doesn't provide. It would at least take care of Level
1 compliance. Just my two cents :)
>
>>
>> The ability to build up a publication in Lenya from an existing site
>> using drag and drop is really nice :).
>
> I think this depends very much on what the existing site is based.
Dreamweaver template based. Currently using dreamweaver to restructure
[including renaming files] my site to fit into Lenya default based
publication [dreamweaver fixes links as you move things around].
--Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Doug Chestnut wrote:
> I like the webDAV approach because one can use it with so many
> different editors. Most desktop web editors support webDAV and have
> for a while. If the editor doesn't support webDAV, well, just make a
> web folder (windows) or mount_webdav (mac, which doesn't work yet,
> think it doesn't like the way the depth header isn't respected
> currently).
as mentioned in my email to Gregor, OSR-101 is not about editing only,
whereas
it's a minor part in it, but a good topic to start with.
But WebDAV is just not sufficient for this purpose.
>
> The ability to build up a publication in Lenya from an existing site
> using drag and drop is really nice :).
I think this depends very much on what the existing site is based.
Michi
>
> --Doug
>
> Gregor J. Rothfuss wrote:
>
>> Michael Wechner wrote:
>>
>>> I think that's actually a plus ;-), because it hopefully
>>> means you tend to a more generic approach.
>>
>>
>>
>> considering that CMS are written in all kinds of languages and
>> running on all kinds of platforms, a protocol-based approach seems
>> the only sensible choice. we already use PUT in many editors, and
>> kupu models the WebDAV model of resources and collections.
>>
>> http://codespeak.net/svn/kupu/trunk/kupu/doc/LIBRARIES.txt has more
>> on this. lenya 1.4 now has webdav support. ideally, custom config
>> details could be determined via PROPGET.
>>
>> as far as i understand, both kupu and bxe already ship with a js
>> webdav library. ironically, it seems to have originated in an earlier
>> oscom effort: http://twingle.mozdev.org/
>>
>> how is OSR-1 different from twingle? it seems to me it would make
>> more sense to finish what we started with twingle long ago rather
>> than embark on a new mission to rediscover the same solutions :)
>>
>> twingle has since been partly incorporated into kupu (and parts into
>> bxe as well), from what i understand
>>
>> the other protocol, the ATOM api, would also be nice, but would not
>> play nicely with desktop applications (where webdav is really the story)
>>
>> WDYT?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Doug Chestnut <ch...@apache.org>.
I like the webDAV approach because one can use it with so many different
editors. Most desktop web editors support webDAV and have for a while.
If the editor doesn't support webDAV, well, just make a web folder
(windows) or mount_webdav (mac, which doesn't work yet, think it doesn't
like the way the depth header isn't respected currently).
The ability to build up a publication in Lenya from an existing site
using drag and drop is really nice :).
--Doug
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> I think that's actually a plus ;-), because it hopefully
>> means you tend to a more generic approach.
>
>
> considering that CMS are written in all kinds of languages and running
> on all kinds of platforms, a protocol-based approach seems the only
> sensible choice. we already use PUT in many editors, and kupu models the
> WebDAV model of resources and collections.
>
> http://codespeak.net/svn/kupu/trunk/kupu/doc/LIBRARIES.txt has more on
> this. lenya 1.4 now has webdav support. ideally, custom config details
> could be determined via PROPGET.
>
> as far as i understand, both kupu and bxe already ship with a js webdav
> library. ironically, it seems to have originated in an earlier oscom
> effort: http://twingle.mozdev.org/
>
> how is OSR-1 different from twingle? it seems to me it would make more
> sense to finish what we started with twingle long ago rather than embark
> on a new mission to rediscover the same solutions :)
>
> twingle has since been partly incorporated into kupu (and parts into bxe
> as well), from what i understand
>
> the other protocol, the ATOM api, would also be nice, but would not play
> nicely with desktop applications (where webdav is really the story)
>
> WDYT?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> I think it's very clear where it is leading and that it might take
>> some time,
>> but again and again it's about getting started and that's the whole
>> point.
>
>
> i have no idea what you intend to do with things like
>
> <cmui>
> <response type="edit-new">
> <edit-new>
> <templates>
> <template name="Letter" src="http://foo.bar/letter.xml"/>
> <template name="Article" src="http://foo.bar/article.xml"/>
> </templates>
> </edit-new>
> </response>
> </cmui>
that's an example how one could imagine the server responding to the
"New" request
>
> but it's a *long* way from coming up with random xml like that to
> something useful.
it's not random at all, but rather straightforward. We implemented
something similar
into a flash based editor and it works just fine, and cannot imagine why
it shouldn't work for any other "editors".
>
>
>> I think pure WebDAV is just a too little step and just not sufficient.
>> Whereas WebDAV might be useful for specific things, but that's what
>> needs
>> to be figured out.
>
>
> webdav is useful and proven for abstracting editing of web ressources,
> which is the scope of this SOC proposal. i don't see how the markup
> above adds anything at all to the problem at hand.
as I said it's about the bigger picture. The problem which is described
within the proposal is just part of the bigger picture.
>
>> But you can only do this by being aware of the bigger picture.
>> And this why I think Zhiwu should work within the "framework" of
>> OSR-101.
>
>
> you will have to heavily extend that document first. currently, there
> is no framework there.
agreed. I perfectly understand that Zhiwu "applied" from a slightly
different angle and my intention is not to force anyone into this bigger
picture.
But I think Zhiwu should talk for himself and see what he feels
comfortable with and hopefully not being afraid making up his mind.
Unfortunately I have realized to late what was proposed re the editors
integration,
otherwise I would have made my suggestions earlier.
But anyway, all I am saying is that the opportunity is there. It's up
to Zhiwu to decide how he wants to tackle this (and maybe risk his
"salary").
Michi
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> I think it's very clear where it is leading and that it might take some
> time,
> but again and again it's about getting started and that's the whole point.
i have no idea what you intend to do with things like
<cmui>
<response type="edit-new">
<edit-new>
<templates>
<template name="Letter" src="http://foo.bar/letter.xml"/>
<template name="Article" src="http://foo.bar/article.xml"/>
</templates>
</edit-new>
</response>
</cmui>
but it's a *long* way from coming up with random xml like that to
something useful.
> I think pure WebDAV is just a too little step and just not sufficient.
> Whereas WebDAV might be useful for specific things, but that's what needs
> to be figured out.
webdav is useful and proven for abstracting editing of web ressources,
which is the scope of this SOC proposal. i don't see how the markup
above adds anything at all to the problem at hand.
> But you can only do this by being aware of the bigger picture.
> And this why I think Zhiwu should work within the "framework" of OSR-101.
you will have to heavily extend that document first. currently, there is
no framework there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> Gregor J. Rothfuss wrote:
>>
>>> Michael Wechner wrote:
>>>
>>>> OSR-101 is not about editing. Editing is just one minor part.
>>>> OSR-101 is about
>>>> the whole CMS user interface.
>>>
>>>
>>>
>>>
>>> well, in that case it is out of scope.
>>
>>
>>
>>
>> why?
>>
>> It's not my idea to think that Zhiwu should implement the whole spec,
>> but
>> part of the editing part.
>
>
> Sorry for my ignorance ... where is the spec which is to be implemented?
>
> You're not referring to http://www.wyona.org/osr-101/osr-101.xhtml,
> are you?
yes
> Or is writing the spec part of the project?
yes. Again, just a part of it, the editing part
> IMO that could be an interesting
> research topic, but it'll certainly busy a team of several people for
> several
> months, without knowing where it will lead ...
I think it's very clear where it is leading and that it might take some
time,
but again and again it's about getting started and that's the whole point.
I am not forcing anyone, but I am saying hey look here is a great
opportunity
and I think it would make a lot of sense to do it.
>
> Would you mind adding some explanatory sections to the spec request
> (purpose, scope, ...)?
yes, I will do over the next couple of days.
Michi
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>> Or is writing the spec part of the project? IMO that could be an
>> interesting
>> research topic, but it'll certainly busy a team of several people for
>> several
>> months, without knowing where it will lead ...
>
>
> exactly. zhiwu has his work cut out for him without having to follow
> non-existent specs.
he will need not to write specs anyway. So why not do it this way?
> which is why leveraging webdav is the way to go.
I think pure WebDAV is just a too little step and just not sufficient.
Whereas WebDAV might be useful for specific things, but that's what needs
to be figured out. But you can only do this by being aware of the bigger
picture.
And this why I think Zhiwu should work within the "framework" of OSR-101.
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> Or is writing the spec part of the project? IMO that could be an
> interesting
> research topic, but it'll certainly busy a team of several people for
> several
> months, without knowing where it will lead ...
exactly. zhiwu has his work cut out for him without having to follow
non-existent specs. which is why leveraging webdav is the way to go.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Gregor J. Rothfuss wrote:
>
>> Michael Wechner wrote:
>>
>>> OSR-101 is not about editing. Editing is just one minor part. OSR-101
>>> is about
>>> the whole CMS user interface.
>>
>>
>>
>> well, in that case it is out of scope.
>
>
>
> why?
>
> It's not my idea to think that Zhiwu should implement the whole spec, but
> part of the editing part.
Sorry for my ignorance ... where is the spec which is to be implemented?
You're not referring to http://www.wyona.org/osr-101/osr-101.xhtml, are you?
Or is writing the spec part of the project? IMO that could be an interesting
research topic, but it'll certainly busy a team of several people for several
months, without knowing where it will lead ...
Would you mind adding some explanatory sections to the spec request
(purpose, scope, ...)?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> OSR-101 is not about editing. Editing is just one minor part. OSR-101
>> is about
>> the whole CMS user interface.
>
>
> well, in that case it is out of scope.
why?
It's not my idea to think that Zhiwu should implement the whole spec, but
part of the editing part.
I think it would be a great opportunity to finally clean up this and really
make a step ahead.
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> OSR-101 is not about editing. Editing is just one minor part. OSR-101 is
> about
> the whole CMS user interface.
well, in that case it is out of scope.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> I think that's actually a plus ;-), because it hopefully
>> means you tend to a more generic approach.
>
>
> considering that CMS are written in all kinds of languages and running
> on all kinds of platforms, a protocol-based approach seems the only
> sensible choice. we already use PUT in many editors, and kupu models
> the WebDAV model of resources and collections.
WebDAV is just not sufficient. OSR-101 is not just about editing, it's about
all common CMS functionalities.
>
> http://codespeak.net/svn/kupu/trunk/kupu/doc/LIBRARIES.txt has more on
> this. lenya 1.4 now has webdav support. ideally, custom config details
> could be determined via PROPGET.
>
> as far as i understand, both kupu and bxe already ship with a js
> webdav library. ironically, it seems to have originated in an earlier
> oscom effort: http://twingle.mozdev.org/
>
> how is OSR-1 different from twingle?
Twingle was focusing on a specific solution and was just taking care of
opening, editing, and closing documents.
> it seems to me it would make more sense to finish what we started with
> twingle long ago rather than embark on a new mission to rediscover the
> same solutions :)
it's not the same
>
> twingle has since been partly incorporated into kupu (and parts into
> bxe as well), from what i understand
OSR-101 is not about editing. Editing is just one minor part. OSR-101 is
about
the whole CMS user interface.
>
> the other protocol, the ATOM api,
the ATOM API has some good ideas, but also needs generalization.
Michi
> would also be nice, but would not play nicely with desktop
> applications (where webdav is really the story)
>
> WDYT?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> I think that's actually a plus ;-), because it hopefully
> means you tend to a more generic approach.
considering that CMS are written in all kinds of languages and running
on all kinds of platforms, a protocol-based approach seems the only
sensible choice. we already use PUT in many editors, and kupu models the
WebDAV model of resources and collections.
http://codespeak.net/svn/kupu/trunk/kupu/doc/LIBRARIES.txt has more on
this. lenya 1.4 now has webdav support. ideally, custom config details
could be determined via PROPGET.
as far as i understand, both kupu and bxe already ship with a js webdav
library. ironically, it seems to have originated in an earlier oscom
effort: http://twingle.mozdev.org/
how is OSR-1 different from twingle? it seems to me it would make more
sense to finish what we started with twingle long ago rather than embark
on a new mission to rediscover the same solutions :)
twingle has since been partly incorporated into kupu (and parts into bxe
as well), from what i understand
the other protocol, the ATOM api, would also be nice, but would not play
nicely with desktop applications (where webdav is really the story)
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Zhiwu Xie wrote:
>However the question remains that if an editor does not support
>certain things shall we just leave it and lose certain functionality,
>
>
one thing we can do is introduce various levels of compliance, e.g.
re editing
Level 1) New, Open, Save, Save As, Exit
Level 2) Save All, Close, Close All
>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?
>
for instance specific "lookups" can be part of higher compliance level
> 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?
>
>
I am not sure if I fully understand. What exactly do you mean
by tightly coupled editor and external editor?
>At this stage I have almost no idea how Lenya works so the above
>question is only speculation.
>
I think that's actually a plus ;-), because it hopefully
means you tend to a more generic approach.
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Zhiwu Xie <zx...@ece.unm.edu>.
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> zxie@ece.unm.edu
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Lenya tutorials
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Zhiwu Xie wrote:
> I'd appreciate very much if you could share any Lenya learning
> materials, tutorial, lecture slides, talk recordings, etc., either for
> absolute newbies or for more advanced users/developers.
http://lenya.apache.org/1_2_x/tutorial/
http://lenya.apache.org/1_2_x/how-to/faq.html
and then the usecase framework in 1.4:
http://lenya.apache.org/1_4/reference/usecase-framework/index.html
note that the tutorials above are written for 1.2. most of the concepts
are the same (sitemaps, etc), but the implementation is different. 1.4
uses java where 1.2 uses a combination of xsp, ant tasks and java.
the usecase framework ties it all together, and will give you a
(hopefully gentle) introduction to the API.
http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/webapp/lenya/usecases/edit/
http://svn.apache.org/viewcvs.cgi/lenya/trunk/src/java/org/apache/lenya/cms/editors/
are most relevant to what you are doing.
-gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Lenya tutorials
Posted by Zhiwu Xie <zx...@ece.unm.edu>.
Hi all,
I'd appreciate very much if you could share any Lenya learning
materials, tutorial, lecture slides, talk recordings, etc., either for
absolute newbies or for more advanced users/developers.
Many thanks,
Zhiwu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
> Michael Wechner wrote:
>
>> Of course the Lenya project shouldn't slow down because the maybe
>> problem
>> of consensus finding, but currently I don't see the problem there,
>> because
>> the group is still small, whereas it will hopefully grow.
>
>
> i'm not aware of any discussion on this at OSCOM. can you point me to
> the group you speak of?
the group currently consist out of Chregu and myself. I have asked
today the Silva/Infrae guys and Laurens and Lon from Xopus/Q42 to join
as well,
but am still waiting for an answer.
I have posted the idea on OSCOM some time ago, but didn't receive any
feedback really, so I started to take action myself. I would happy to
move this to OSCOM
at some later stage if we can actually generate some momentum.
Michi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> Of course the Lenya project shouldn't slow down because the maybe problem
> of consensus finding, but currently I don't see the problem there, because
> the group is still small, whereas it will hopefully grow.
i'm not aware of any discussion on this at OSCOM. can you point me to
the group you speak of?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: welcome to summer of code, Zhiwu Xie!
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
>
> Synopsis
> --------
>
> This project will investigate and implement the editor plug-in APIs
> for Lenya, an open source Java/XML Content Management System.
It just comes to my mind that this would fit in perfectly within OSR-101
http://www.wyona.org/osr-101/index.html
http://www.wyona.org/osr-101/osr-101.xhtml
http://www.wyona.org/osr-101/FutureCMSArchitecture.pdf
especially within the Editor part of it.
I think it would be good if Lenya wouldn't build a "Lenya" only spec,
but rather listen to the input from other sides as well, e.g. BitfluxCMS,
Silva (Infrae), Xopus, etc.
Of course the Lenya project shouldn't slow down because the maybe problem
of consensus finding, but currently I don't see the problem there, because
the group is still small, whereas it will hopefully grow.
WDYT?
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org