nectar-announce — Low Traffic Announcement List

[Kai S. <sch...@cs...>]

Hello,

This is a quick status report on the Nectar WebServices project. We're 
currently in the process of writing a lot of new documentation, and so 
it seemed a fitting time to also write up this report and send it to our 
mailing lists.


--- Status

Nectar is still, and will be for a while, considered by it's creator to 
be an early prototype. Much of the main API is still evolving and 
changing, so developpers should only use Nectar for prototypes, not 
"serious development". Even during the massive transformations that 
Nectar is currently going through (see Recent Changes below), it can run 
websites in decent stability.

Nectar has been used as a base for ACID, a chemical inventory storage 
system for universities' chemistry departments. ACID, while only a 
prototype,  has received a lot of praise for it's easy going, yet very 
strict design, as well as for it's fundamental features of robustness 
and security. ACID could not have been built the way it was without the 
base of Nectar.

The last release of Nectar dates back to September 2004, and is rudely 
out of date. The current code is very different and undergoing heavy 
changes still. The next release of Nectar will not come for at least a 
few more months, and the CVS server is currently closed to the public, 
until we figure out a better licensing system. Any developpers 
interested in looking at the code should contact Kai Schutte 
(sch...@cs...) for access to the CVS server (read Licensing 
Issues, below).


--- People

Currently, the developpers of Nectar are Kai Schutte and Royce Ausburn. 
We are hoping for more people to join us, as our volunteer and 
restricted schedules severely limit the amount of time we are able to 
work on the project.


--- Goals

The primary goal of Nectar hasn't changed: to provide a robust, secure 
and scalable web application platform, that remains highly extensible 
through a very simple but strict design.

Our current goals are:

- to make the Nectar code base more easily available by designing a 
common build system, which would allow all potential developpers to 
download the code, then modify and build (compile) it without much delay 
or complications.

- to clearly define extension design. We aim to make extensions 
extremely portable, up to the point where a system running Nectar can 
simply download and run an extension without user interaction, nor even 
requiring a restart of the Nectar programme.

- to simplify the design of Query's and the DataAdapterSerivce, so as to 
allow very small amounts of code in the Action classes to do a very 
large amount of work. (see More Info: Data Services section below)

- to add Java 1.5.0 Generics support to the base distribution, which 
will simplify and rigidify a lot of the base code, as well as it's API. 
Java 1.4.0 code will still be compatible, but will give many warnings. 
(see http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html 
for more info on Generics)

- to start building a foundation for the clustering system. This means 
ripping out much of the Struts and Servlet dependancies (you'll be able 
to run Nectar as a standalone app!), then designing and implementing a 
communication framework that would allow several Nectar nodes to run a 
single project.

- to build up documentation, primarily through a wiki, which is now 
online at http://nectar.sourceforge.net/

- to integrate Dynamic Forms (so you don't have to write a Form class 
for every Action).

- to support Python as an Action and Form writing language! Python 
scripts will run as an interpreted language they will be stored in the 
database, so developpers could edit Actions directly over the web, 
without compilation or anything!

- to move validation checks to the database, and implement tools to 
configure validation checks.

- to allow Nectar to restart "softly", meaning that it should block all 
requests, clear out all it's memory, and restart afresh (re - reading 
configurations) and start processing requests again without any downtime 
(unless the request queue overflows).

- to replace the current commons-logging interface with something 
inhouse that would store log events to the database, and use the same 
system to log requests and user actions, paving the groundwork for an 
activity tracking extension.

- to define a universal data definition schema that would describe 
Record storage settings for SQL and OODBMS, and any other future 
DataAdapaterService implementation. This schema needs to be machine 
parsable and translatable to a series of commands to create this 
definition in SQL, OODMS or whatever else. This schema also needs to be 
used to convert actual data from one implementation to another.


-- Major Recent Changes

- Page configuration is now entirely in the database. An online page 
configuration tool is yet to be written.

- Message Resources are now in the database.

- Query Caching is nearly ready, but is waiting for major changes in the 
data services to go live. Record Caching works fine as usual.

- Asynchronous queries: in actions you can now launch many independant 
queries, let some other code execute, then "pick up" the results from 
your queries in any order.

- Multiple projects on a single server now work as they should, but 
configuration is difficult until a page configuration tool is written.

- The Reda Administration tool is very broken at the moment, and won't 
get much loving for a while.

- The web page generating code which used to be part of the base 
distribution has been moved to a base extension, which will be released 
under a totally free license (free to re-release under any license).


-- Licensing Issues

The main reason why we are currently not planning to make a new release 
is that we are looking for the right licenses to release different parts 
of Nectar. We do want to keep Nectar as open as possible, especially for 
non-commercial users. We also want to be able to provide a ton of sample 
code under a completely free license, allowing republishing under any 
license (including the most restrictive types). Finally, we do want to 
receive a small compensation from any systems that use Nectar for 
profit, either through direct use or from reselling the hosting of 
Nectar, in order to allow us to continue working on the project. We are 
looking at a variety of licenses at the moment, but in the end, we would 
need a lawyer / businessperson specializing in the field to guide us. 
The next release of Nectar will be under a new set of licenses that 
match our goal, which is to build a project that is very open and 
useful, but in the end can help us financially, to develop and market 
the project further, without hindering a not-for-profit base of users.


-- More Information

The official website of the Nectar WebServices project is a Wiki, 
located at http://nectar.sourceforge.net/

To receive intermittent updates about the project, you may join the 
nectar-announce mailing list at 
http://lists.sourceforge.net/lists/listinfo/nectar-announce

To receive general developper communication about the project, you can 
join the nectar-devel mailing list at 
http://lists.sourceforge.net/lists/listinfo/nectar-devel (note that all 
announce messages are crossposted to the devel list, so no need to 
subsribe to both)

Finally, you may contact the main programmers directly, Kai Schutte at 
sch...@cs..., or Royce Ausburn at aus...@cs....



- The Nectar WebServices Team.