incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Incubator Wiki] Update of "CaitrinProposal" by acymbalak
Date Tue, 15 Jul 2008 18:44:44 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The following page has been changed by acymbalak:
http://wiki.apache.org/incubator/CaitrinProposal

------------------------------------------------------------------------------
  As has been mentioned on the general@ list, this is in need of a name change but no name
has been decided on yet.  When it is, all the names (jira, maillists, etc.) will all be updated
to reflect the new name.
  
  == Abstract ==
- Caitrin will be a photo gallery application.
+ *Insert name here* will be a photo gallery application.
  
  == Proposal ==
- Caitrin will be an open source photo gallery application consisting of the display piece,
user management and upload capabilities.  As Web 2.0 continues to catch on more site administrators
are wanting to provide others with a way to publish their own content, including pictures.
 Caitrin will provide a way to do this.
+ *Insert name here* will be an open source photo gallery application consisting of the display
piece, user management and upload capabilities.  As Web 2.0 continues to catch on more site
administrators are wanting to provide others with a way to publish their own content, including
pictures.  *Insert name here* will provide a way to do this.
  
- There are still many questions that need to be answered regarding this application.  They
are all asked with their appropriate topic but summarized here:
- 
-  * Should the user management default be Apache Directory or a simple database?
-  * Will the Web service just provide data for machine to machine exchanges or will it default
to human readable?
-  * Should the project impose a backend data storage mechanism and schema, or just WS/REST
interfaces suitable for pluggable frontends?
-  * Should we use JCR or a (relational) Database?
-   * The proposal (below) now presumes JCR.  Are we losing anything by not having a relational
database?
- 
- This project will have both the back end and the front end needed for a complete gallery.
 The proposal is to have a rigid design for the content with a very flexible display piece.
+ This project will have both the back end and the front end needed for a complete gallery.
 The proposal is to have a rigid design for the content with a very flexible display piece.
User management will allow for granular control over security of the images themselves.
- 
- The photos and meta data will be exposed via a Web service.  During discussions on the lists
regarding how the code should be written, the one thing that no one seemed to be able to agree
on was how the photos should be displayed.  Some would like to see them in Flash, others AJAX,
still others as a JSP library.  Exposing the information as a Web service allows for each
of these display formats to be utilized.  Question: Will the Web service just provide data
for machine to machine exchanges or will it default to being human readable?  If it only provides
for machine to machine exchanges then a default option for display will need to be provided.
 We plan on looking at the Tuscany SCA implementation to facilitate the WS.
- 
- The user management system will be based on JAAS.  It should be implemented in such a way
that it can also be flexible.  An end user should be able to integrate any existing user authentication
tool against it.  Question: should the default be Apache Directory or a simple database? 
User authorization will facilitate photos being marked as public (anyone), protected (invite
only), or private (just the owner).
- 
- The storage for all data will use Apache Jackrabbit and as logically follows Sling.  The
actual node and property structure has yet to be determined.  Questions: Should the project
impose a backend data storage mechanism and schema, or just WS/REST interfaces suitable for
pluggable frontends?  Should we use JCR or a (relational) Database?
  
  == Background ==
- Caitrin was initially developed to meet the need for a photo gallery during a project at
Nechtan Design.  There was not an open source answer to the need for a photo gallery that
was written in Java so we took the initiative to write one.  Following the initial development
of the code, which was a paid project, I continued to develop the code on a volunteer basis
after seeing a need for this code in the community.  Recognizing that I am just one person
and that this project needs to have a community around it, I decided to look into turning
the code over to the ASF and joining with them to develop this into the type of product it
should be.
+ Initially the proposal idea for a photo gallery was brought forth due to a project that
had been started at Nechtan Design.  While discussing the possibility of forming a community
around that project (called Caitrin) a community started to form.  Others with interest in
the subject and problem space started putting in their ideas and offered to donate code that
could help.  It was decided that the project should start from scratch with a new architecture.
 With this decision, the high level design below was started.
  
- After discussions with others at the ASF, it appears that a community can be found for the
project.  There are 3 sets of code that I am aware of that can be both drawn from and discarded
as the application grows.  It will no longer be starting with the code developed at Nechtan
Design but rather drawing bits and pieces as needed.
+ We are aware that we have significant work ahead of us, not only in the code to be written
but in finding a community to support the project.
  
  == Rationale ==
  "A picture tells a thousand words..."
  
- If a picture tells a thousand words then a gallery of pictures tells an amazing story. 
It could tell this story as part of a larger web site, in a blog or on its own.  Unfortunately,
there exists no Java open source application to assist the community to tell this story. 
Caitrin will change that.
+ If a picture tells a thousand words then a gallery of pictures tells an amazing story. 
It could tell this story as part of a larger web site, in a blog or on its own.  Unfortunately,
there exists no Java open source application to assist the community to tell this story. 
*Insert name here* will change that.
  
- There are many photo galleries that are written in PHP.  Each of these addresses a particular
need and many work well for their intended purpose.  However, there is not a photo gallery
that is written in Java.  As Web 2.0 continues to grow it only makes sense that the community
provide not only PHP but also Java applications to allow everyone the ability to publish their
own content.  Apache started down this road with Roller and can continue with Caitrin.
+ There are many photo galleries that are written in PHP.  Each of these addresses a particular
need and many work well for their intended purpose.  However, there is not a photo gallery
that is written in Java.  As Web 2.0 continues to grow it only makes sense that the community
provide not only PHP but also Java applications to allow everyone the ability to publish their
own content.  Apache started down this road with Roller and can continue with *Insert name
here*.
  == Initial Goals ==
   * Decide which pieces of code can be drawn from existing projects
   * Recruit additional community members
@@ -57, +43 @@

     * Use cases - want to capture ideas for process (Ode) integration
     * WSDL Description
     * prototype
+ === High Level Design ===
+ There are still many questions that need to be answered regarding this application.  They
are all asked with their appropriate topic but summarized here:
+ 
+  * Should the user management default be Apache Directory or a simple database?
+  * Will the Web service just provide data for machine to machine exchanges or will it default
to human readable?
+  * Should the project impose a backend data storage mechanism and schema, or just WS/REST
interfaces suitable for pluggable frontends?
+  * Should we use JCR or a (relational) Database?
+   * The proposal (below) now presumes JCR.  Are we losing anything by not having a relational
database?
+ 
+ The photos and meta data will be exposed via a Web service.  During discussions on the lists
regarding how the code should be written, the one thing that no one seemed to be able to agree
on was how the photos should be displayed.  Some would like to see them in Flash, others AJAX,
still others as a JSP library.  Exposing the information as a Web service allows for each
of these display formats to be utilized.  Question: Will the Web service just provide data
for machine to machine exchanges or will it default to being human readable?  If it only provides
for machine to machine exchanges then a default option for display will need to be provided.
 We plan on looking at the Tuscany SCA implementation to facilitate the WS.
+ 
+ The user management system will be based on JAAS.  It should be implemented in such a way
that it can also be flexible.  An end user should be able to integrate any existing user authentication
tool against it.  Question: should the default be Apache Directory or a simple database? 
User authorization will facilitate photos being marked as public (anyone), protected (invite
only), or private (just the owner).
+ 
+ The storage for all data will use Apache Jackrabbit and as logically follows Sling.  The
actual node and property structure has yet to be determined.  Questions: Should the project
impose a backend data storage mechanism and schema, or just WS/REST interfaces suitable for
pluggable frontends?  Should we use JCR or a (relational) Database?
  
  == Current Status ==
- There are 3 code bases that will be available to draw from when starting the project.  Currently,
due to a drastic change in architecture, we are at the very beginning of the project.  Discussions
are ongoing on the projects@ list.
+ There are 4 code bases that will be available to draw from when starting the project.  Currently,
due to a 
+ drastic change in architecture, we are at the very beginning of the project.
+ 
+ The code bases are as follows:
+ 
+ Codebase 1
+ ----
+ Originally developed for a fee at Nechtan Design then voluntarily updated.[[BR]]
+ Code is in use on a test site and ready to be moved to production.[[BR]]
+ Technologies: Java, Tomcat, relational DB backend, integration with Roller suggested but
currently no dependency[[BR]]
+ 
+ Codebase 2
+ ----
+ Developed by Noel Bergman.[[BR]]
+ Code in production use.[[BR]]
+ No technical details.[[BR]]
+ 
+ Codebase 3
+ ----
+ Developed by Carsten Ziegeler.[[BR]]
+ Code not ready to be shared yet.[[BR]]
+ Technologies: Sling frontend, JCR backend.[[BR]]
+ 
+ Codebase 4
+ ----
+ Developed by Luciano Resende.[[BR]]
+ Prototype available.[[BR]]
+ Technologies: Tuscany front end, file-based backend.[[BR]]
+ 
  == Meritocracy ==
- The Caitrin project will demonstrate the best in meritocracy.  Due to the fact that the
project is in its infancy and no community currently exists, the community that grows to surround
it as it grows within the ASF will all adhere to the fundamentals of meritocracy.
+ The Caitrin project will demonstrate the best in meritocracy.  Due to the fact that the
project is in its infancy and only a small community exists, the community that grows to surround
it as it grows within the ASF will all adhere to the fundamentals of meritocracy.  Every person
who is currently part of the community has code that they have developed yet are willing to
rewrite for the good of the project.
+ 
  == Community ==
- At this time Caitrin has not been released as an open source project and therefore does
not have a community surrounding it.  However, I firmly believe that a community of developers
exists for this type of project.
+ At this time a small community has been found within the ASF.  We intend to continue to
grow this community as the project picks up steam.
+ 
  == Core Developers ==
  Angela Cymbalak
+ 
  == Alignment ==
  == Known Risks ==
  === Orphaned Projects ===
- This could be a problem and it is one that I recognize.  I have no intention of abandoning
this code because there appears to be a need for it and I have continued to work on it even
without being paid.  However, as the community grows around it others will take on more of
a role than even I currently have.
+ 
  === Inexperience with Open Source ===
+ Of the existing community, only one member has limited experience with open source.  She
is committed to learning the Apache Way.
+ 
  === Homogeneous Developers ===
- There is no community but there is a commitment to develop a community.  As part of that
commitment I recognize that have a diverse community is essential.  The exchange of ideas
is much better for everyone when those ideas of different.
+ The current community grew out of a desire to see different pieces of technology put to
use and an interest in the problem space.  There is no single entity that is providing all
the developers for this project.
+ 
  === Reliance on Salaried Developers ===
- The initial code base was not developed by salaried developers.  It was developed to meet
a need that was not being fulfilled by other open source applications.
+ This project is not in the profit stream for any of the participants.
+ 
  === Relationships with Other Apache Products ===
- The current Caitrin code utilizes code from the Commons project and is designed to run within
Tomcat. 
+ There are several other Apache Products and Apache Incubator projects that are being evaluated
for use with this project.
  
- Relationships are starting for form with the Apache Jackrabbit, Sling and Tuscany projects.
 It appears that the code from these projects can be used to build large portions of the Caitrin
software.
+ Jackrabbit - Java Content Repository
+ http://jackrabbit.apache.org/
+ Standard API for content repository, supports versioning.
+ Backend adapters can map to file system, DB,...
+ 
+ Tomcat - Servlet & JSP Container
+ http://tomcat.apache.org/
+ 
+ Tuscany - infrastructure for Service Oriented Architecture
+ http://tuscany.apache.org/
+ 
+ Sling - framework for web apps with JCR backend
+ http://incubator.apache.org/sling/site/index.html
+ 
+ Sanselan - image manipulation library
+ http://incubator.apache.org/sanselan/
+ 
+ There has been mention of using a Cocoon block for image resizing.
+ 
  
  === A Excessive Fascination with the Apache Brand ===
- I chose the Apache Foundation to bring this code and idea to not because of the Apache brand
but the Apache community.  The Apache community has shown themselves to be invested in the
code that they are writing because they enjoy the act of developing a quality product that
can be easily used by others.  They rely on collective knowledge instead of the knowledge
of the individual and are willing to share that knowledge with others.  I have used many of
the Apache products in the past and felt that this application would grow well under the guidance,
leadership and structure of the Apache community and the ASF.
+ The Apache community has shown themselves to be invested in the code that they are writing
because they enjoy the act of developing a quality product that can be easily used by others.
 They rely on collective knowledge instead of the knowledge of the individual and are willing
to share that knowledge with others.  We feel that this application will continue to grow
well under the guidance, leadership and structure of the Apache community and the ASF.
  == Documentation ==
  No documentation currently exists.
  == Initial Source ==
- No initial source is currently identified.  There are 3 individual code bases that may be
drawn from but only one that currently looks to implement the proposal.  This code was written
as an example for Sling.
+ No initial source is currently identified.  All the code bases listed above will be donated
in order to prevent IP pollution.
  == Cryptography ==
  No cryptography is currently utilized in this project.
  == Required Resources ==
  === Mailing lists ===
  The minimum mailing lists will be needed:
-  * caitrin-private (with moderated subscriptions)
+  * *Insert name here*-private (with moderated subscriptions)
-  * caitrin-dev
-  * caitrin-commits
-  * caitrin-user
+  * *Insert name here*-dev
+  * *Insert name here*-commits
+  * *Insert name here*-user
  === Subversion Directory ===
- https://svn.apache.org/repos/asf/incubator/caitrin
+ https://svn.apache.org/repos/asf/incubator/*Insert name here*
  === Issue Tracking ===
- JIRA Caitrin(Caitrin)
+ JIRA *Insert name here*(*Insert name here*)
  === Other Resources ===
  None.
  == Initial Committers ==
@@ -115, +168 @@

  [[BR]]
  ''Help is needed.''
  == Sponsoring Entity ==
- I kindly ask the Incubator to take in this project.
+ We kindly ask the Incubator to take in this project.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message