nectar-devel — Nectar WebServices Developer List

[Nectar-devel] Best offer

[englebart m. <jg...@at...>]

Erectile Dysfunction Medication, fast delivery see here

Re: [Nectar-devel] Kicking out MySQL, greeting Postgres, and the RecordKeeper tool...

[Royce A. <124...@cs...>]

I'm all for the naive expedition to implement our own db...


> I started off the day trying to fix up the MySQLDataAdapter, mainly the
> MySQLQueryRenderer class... It's a MESS!! and needs a complete rewrite
> if it's to work with the "modern" version of Records and Queries...
>
> Before I go off on that adventure, I wanted to check out what SQL views
> in PostgreSQL could do for me. After much struggling with a 1200 page
> manual and a psql GUI client that kept crashing or misbehaving on me, I
> finally figured things out...
>
> The issue with using 'plain' tables as they're used in MySQL is that
> each Record is spread over at least two tables (nectar_record_Record and
> for example, nectar_record_PersonRecord). So a select query has to be
> able to figure out how a query on one table reflects on the other tables
> it inherits from... It's doable in Nectar, but intensely complicated.
> With views, you make the DB server do all that work, by making it merge
> the two (or more) tables before the query comes in. so... in MySQL, you
> have to do:
>
> SELECT id FROM record, person WHERE (person.name_first = 'kai' and
> record.id = person.id and record.project = '1234');
>
> if you have an inherited record, you have to do:
>
> SELECT id FROM record, person, customer WHERE (person.name_first =
> 'client' and customer.credit_card = 'full' and record.id = person.id and
> customer.id = record.id and record.project = '1234');
>
> You can imagine how complex generating these query strings gets when
> you're doing a cross table query on the same table over inherited
> records, like:
>
> CustomerRecord cr1 = new CustomerRecord();
> CustomerRecord cr2 = new CustomerRecord();
> RecordQuery q = new RecordQuery();
> q.addField(cr2.ID);
> q.addOperatorCondition(cr1.FRIEND_OF, cr2.ID);
> q.addOperatorCondition(cr1.ID, myId);
> q.addOrderBy(cr2.LAST_NAME);
> ResultList list = executeList(q);
>
> would have to generate:
>
> SELECT table0.id FROM record as table0, record as table1, person as
> table2, person as table3, customer as table4, customer as table5 WHERE
> (table1.id = '$myID' AND table1.friendOf = table0.id AND table1.id =
> table3.id AND table0 = table2.id AND table4.id = table0.id AND table5.id
> = table1.id AND table1.project = '1234' AND table0.project = '1234')
> ORDER BY table2.last_name;
>
> Keeping all the aliases straight is one problem, mapping all the fields
> to the right tables is another... It's possible... but... difficult...
>
> Now... in PostgreSQL with views, here's that same SQL query:
>
> SELECT table0.id FROM costumer as table0, costumer as table1 where
> (table1 = '$myId' AND table1.friendOf = table0.id AND table0.project =
> '1234' and table1.project = '1234') ORDER BY table0.last_name;
>
> With views, PostgreSQL already knows that 'customer' is already a joined
> table from record, person and customer.
>
> This also simplifies INSERT and UPDATE statements greatly, as you can
> update an inherited record in a single query, while in MySQL, you'd have
> to do 2 or more INSERT or UPDATE queries to get your changes. These
> changing queries where always risky in MySQL since it doesn't support
> transactions fully... so you were able to insert a row into the record
> table, but then have it fail on the person table, and you'd end up with
> an orphaned record row. Postgresql is fully transaction based, so if
> anything goes wrong in a whole series of changing queries, it will just
> revert everything.
>
> MySQL 5.0 just came out and does promise support for views, and
> triggers, etc... I'll take a look... if MySQL 5.0 does support these
> features as nicely as Postgre does, I'll fully boot out the 'simple'
> MySQL support from Nectar... it's not worth the headaches... If it
> supports them only partially, we'll see... if it doesn't, screw MySQL...
>
> ----
>
> In order to get Views to work properly in PostgreSQL, a pretty large
> amount of SQL code is required to define tables, views and other rules
> (for insert/update). Each table that inherits directly from
> nectar.record.Record requires a good 2 printed pages worth of SQL
> code... no way I'm converting all my old record SQL by hand. So... I'm
> gonna take over the RecordGenerator tool that Royce started on...
>
> RecordKeeper will be a Java GUI offline tool that edits an record
> definition XML file. This tool will also generate the Java classes in
> source for Record's, as well as PostGreSQL definition files and, if
> we're going to keep MySQL 5.0 support, MySQL 5.0 table files.
> RecordKeeper will be under the 'tools' subproject of Nectar, package
> nectar.tools.record.*
>
> ----
>
> In more general updates, no subversion commits are upcoming. The
> MySQLDataAdapter is and will remain broken for a while. I will start
> working on a new SQLDataAdapter soon(tm).
>
> -kai
>
>
> !DSPAM:4285fc09290561203765912!
>

[Nectar-devel] Kicking out MySQL, greeting Postgres, and the RecordKeeper tool...

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

I started off the day trying to fix up the MySQLDataAdapter, mainly the 
MySQLQueryRenderer class... It's a MESS!! and needs a complete rewrite 
if it's to work with the "modern" version of Records and Queries...

Before I go off on that adventure, I wanted to check out what SQL views 
in PostgreSQL could do for me. After much struggling with a 1200 page 
manual and a psql GUI client that kept crashing or misbehaving on me, I 
finally figured things out...

The issue with using 'plain' tables as they're used in MySQL is that 
each Record is spread over at least two tables (nectar_record_Record and 
for example, nectar_record_PersonRecord). So a select query has to be 
able to figure out how a query on one table reflects on the other tables 
it inherits from... It's doable in Nectar, but intensely complicated. 
With views, you make the DB server do all that work, by making it merge 
the two (or more) tables before the query comes in. so... in MySQL, you 
have to do:

SELECT id FROM record, person WHERE (person.name_first = 'kai' and 
record.id = person.id and record.project = '1234');

if you have an inherited record, you have to do:

SELECT id FROM record, person, customer WHERE (person.name_first = 
'client' and customer.credit_card = 'full' and record.id = person.id and 
customer.id = record.id and record.project = '1234');

You can imagine how complex generating these query strings gets when 
you're doing a cross table query on the same table over inherited 
records, like:

CustomerRecord cr1 = new CustomerRecord();
CustomerRecord cr2 = new CustomerRecord();
RecordQuery q = new RecordQuery();
q.addField(cr2.ID);
q.addOperatorCondition(cr1.FRIEND_OF, cr2.ID);
q.addOperatorCondition(cr1.ID, myId);
q.addOrderBy(cr2.LAST_NAME);
ResultList list = executeList(q);

would have to generate:

SELECT table0.id FROM record as table0, record as table1, person as 
table2, person as table3, customer as table4, customer as table5 WHERE 
(table1.id = '$myID' AND table1.friendOf = table0.id AND table1.id = 
table3.id AND table0 = table2.id AND table4.id = table0.id AND table5.id 
= table1.id AND table1.project = '1234' AND table0.project = '1234') 
ORDER BY table2.last_name;

Keeping all the aliases straight is one problem, mapping all the fields 
to the right tables is another... It's possible... but... difficult...

Now... in PostgreSQL with views, here's that same SQL query:

SELECT table0.id FROM costumer as table0, costumer as table1 where 
(table1 = '$myId' AND table1.friendOf = table0.id AND table0.project = 
'1234' and table1.project = '1234') ORDER BY table0.last_name;

With views, PostgreSQL already knows that 'customer' is already a joined 
table from record, person and customer.

This also simplifies INSERT and UPDATE statements greatly, as you can 
update an inherited record in a single query, while in MySQL, you'd have 
to do 2 or more INSERT or UPDATE queries to get your changes. These 
changing queries where always risky in MySQL since it doesn't support 
transactions fully... so you were able to insert a row into the record 
table, but then have it fail on the person table, and you'd end up with 
an orphaned record row. Postgresql is fully transaction based, so if 
anything goes wrong in a whole series of changing queries, it will just 
revert everything.

MySQL 5.0 just came out and does promise support for views, and 
triggers, etc... I'll take a look... if MySQL 5.0 does support these 
features as nicely as Postgre does, I'll fully boot out the 'simple' 
MySQL support from Nectar... it's not worth the headaches... If it 
supports them only partially, we'll see... if it doesn't, screw MySQL...

----

In order to get Views to work properly in PostgreSQL, a pretty large 
amount of SQL code is required to define tables, views and other rules 
(for insert/update). Each table that inherits directly from 
nectar.record.Record requires a good 2 printed pages worth of SQL 
code... no way I'm converting all my old record SQL by hand. So... I'm 
gonna take over the RecordGenerator tool that Royce started on...

RecordKeeper will be a Java GUI offline tool that edits an record 
definition XML file. This tool will also generate the Java classes in 
source for Record's, as well as PostGreSQL definition files and, if 
we're going to keep MySQL 5.0 support, MySQL 5.0 table files. 
RecordKeeper will be under the 'tools' subproject of Nectar, package 
nectar.tools.record.*

----

In more general updates, no subversion commits are upcoming. The 
MySQLDataAdapter is and will remain broken for a while. I will start 
working on a new SQLDataAdapter soon(tm).

-kai

Re: [Nectar-devel] Query and Record overhaul...

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

ha!

I still gotta start on that PLDC assignment :( good recovery, mate... 
I've just posted all my changes up to now to subversion. queries won't 
work, but at least the code compiles hehe...

many more changes still to come, this is just to give you an idea of 
what's going on :)

/me is off to Eve for a little ganking >:)

-kai

Royce Ausburn wrote:

>Waa! Between uni, Tanya and getting sick this weekend (caught something
>from my brother =/ ) I've done nothing...Sorry.  I plan to have the PLDC
>assignment finished by Wednesday, then I have some time to work on
>Nectar...Rar!  I'm only doing 3 units and I don't have enough time to code
>ot play WoW!  I've not leveled in 2 weeks and all my friends have
>surpassed me =(
>
>
>Anyways, I'll have a look soon
>
>--Royce
>
>  
>
>>I'm still working on it... I got everything compiling and running again,
>>but realized I made a pretty silly mistake in the bottom of my chain of
>>changes... lovely, ain't it...
>>
>>Basically, much of the changes that I described in the previous mail are
>>done and work, the issue is that the MySQLQueryAdapter cannot really
>>know which field belongs to which table, and how to join tables together
>>over their ID numbers...
>>
>>Sooo... instead of having
>>q.addOp(PersonRecord.ID, id);
>>you'll have to do
>>PersonRecord pr1 = new PersonRecord();
>>q.addOp(pr1.ID, id);
>>
>>which then also solves the issue of not being able to make cross table
>>queries...
>>
>>The interface for defining queries has already massively simplified,
>>though... and this fix will help in that...
>>
>>in the meantime, the MySQLQueryRenderer has become a behemoth of really
>>messy code... will have to clean it up and optimize at some point, but
>>it's not a priority atm...
>>
>>-kai
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: NEC IT Guy Games.
>>Get your fingers limbered up and give it your best shot. 4 great events, 4
>>opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>>win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>>_______________________________________________
>>Nectar-devel mailing list
>>Nec...@li...
>>https://lists.sourceforge.net/lists/listinfo/nectar-devel
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.
>Get your fingers limbered up and give it your best shot. 4 great events, 4
>opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
>win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
>_______________________________________________
>Nectar-devel mailing list
>Nec...@li...
>https://lists.sourceforge.net/lists/listinfo/nectar-devel
>
>
>!DSPAM:427e165d185126573672521!
>
>  
>

Re: [Nectar-devel] Query and Record overhaul...

[Royce A. <124...@cs...>]

Waa! Between uni, Tanya and getting sick this weekend (caught something
from my brother =/ ) I've done nothing...Sorry.  I plan to have the PLDC
assignment finished by Wednesday, then I have some time to work on
Nectar...Rar!  I'm only doing 3 units and I don't have enough time to code
ot play WoW!  I've not leveled in 2 weeks and all my friends have
surpassed me =(


Anyways, I'll have a look soon

--Royce

> I'm still working on it... I got everything compiling and running again,
> but realized I made a pretty silly mistake in the bottom of my chain of
> changes... lovely, ain't it...
>
> Basically, much of the changes that I described in the previous mail are
> done and work, the issue is that the MySQLQueryAdapter cannot really
> know which field belongs to which table, and how to join tables together
> over their ID numbers...
>
> Sooo... instead of having
> q.addOp(PersonRecord.ID, id);
> you'll have to do
> PersonRecord pr1 = new PersonRecord();
> q.addOp(pr1.ID, id);
>
> which then also solves the issue of not being able to make cross table
> queries...
>
> The interface for defining queries has already massively simplified,
> though... and this fix will help in that...
>
> in the meantime, the MySQLQueryRenderer has become a behemoth of really
> messy code... will have to clean it up and optimize at some point, but
> it's not a priority atm...
>
> -kai
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Nectar-devel mailing list
> Nec...@li...
> https://lists.sourceforge.net/lists/listinfo/nectar-devel
>
>
> !DSPAM:427de5c983031307716098!
>
>

Re: [Nectar-devel] Query and Record overhaul...

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

I'm still working on it... I got everything compiling and running again, 
but realized I made a pretty silly mistake in the bottom of my chain of 
changes... lovely, ain't it...

Basically, much of the changes that I described in the previous mail are 
done and work, the issue is that the MySQLQueryAdapter cannot really 
know which field belongs to which table, and how to join tables together 
over their ID numbers...

Sooo... instead of having
q.addOp(PersonRecord.ID, id);
you'll have to do
PersonRecord pr1 = new PersonRecord();
q.addOp(pr1.ID, id);

which then also solves the issue of not being able to make cross table 
queries...

The interface for defining queries has already massively simplified, 
though... and this fix will help in that...

in the meantime, the MySQLQueryRenderer has become a behemoth of really 
messy code... will have to clean it up and optimize at some point, but 
it's not a priority atm...

-kai

[Nectar-devel] Query and Record overhaul...

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

hey,

I'm in the middle of a pretty massive Query and Record overhaul... Here 
are the main changes:

- Record classes no longer define table names explicitly. The 
SQLDataAdapter infers them from the Record's class (ie, table in SQL 
will be 'nectar_record_PersonRecord', instead of 'person')
- the Query class is now abstract, and can be instantiated through 
RecordQuery and ArbitraryQuery. RecordQuery is much more restrictive, 
and only allows queries on Records, while ArbitraryQuery is much more 
loose and can query any table and field. Actions will only be allowed to 
execute RecordQuery's, and while Services may do either, but really 
should only execute ArbitraryQuery's.
- A Record's field can now be referenced through a static final 
Record.RecordField object. One can use this straight in the definition 
of Query objects as a query field, as these RecordFields know which 
Class they belong to, even in a long hierarchy. Data loading and 
unloading from Record objects is done by Java reflection on these static 
RecordFields.
- RecordDataElement classes in nectar.record.datatypes have been cut 
down from around 20 to 5: RecordInteger, RecordString, RecordSet, 
RecordBoolean and RecordDate. Validation of these RecordDataElements 
will be done more generically with  constructs of a DataElementCondition 
class, which will define ranges, etc for a specific Record's field.
- the number of Query methods will grow greatly, to provide many many 
shortcuts. What was previously:

    Query q = new Query(new nectar.record.RecordDescriptor(project, 
ForumRecord.TABLE, owner));
    q.addDataCondition(DataConditions.AND, new OperatorCondition(new 
FieldElement(ForumRecord.TABLE, ForumRecord.FIELD_CATEGORY, 
OperatorCondition.EQUAL, new ValueElement(category)));
    q.addPostElement(new OrderByPostElement(new 
FieldElement(ForumRecord.TABLE, ForumRecord.FIELD_FORUM_NAME)));
    List rows = 
nectar.ServicesUtil.getDataAdapter().readSingleFieldMultipleRow(q);

will now be:

    RecordQuery q = new RecordQuery();
    q.addOp(ForumRecord.OWNER, owner);
    q.addOp(ForumRecord.CATEGORY, category);
    q.addOrderBy(ForumRecord.FORUM_NAME);
    RecordList list = query(q);

Less typing, same funcationality!   (if this is too much shortcuts for 
you, read at the bottom of this mail for a full explanation)

These changes pave the way to making an internal OODBMS possible, which 
would have been very difficult with the current Query / Record API. It 
also should simplify auto-generation of Record class code from XML 
pre-definitions. The changes mainly focus on ease of use, and magically 
simplify both the Record class code as well as using the Query code. 
Much of the complexity has been pushed to the MySQLAdapter, while the 
Query object itself has only grown in it's number of methods, it hasn't 
fattened up in actual code.

While I'm not looking forward to modifying existing package code EVEN 
MORE, this will definetly make Query writing and Record handling easier, 
while making some parts safer, and others finally functional (inherited 
records!!).

The subversion revision implementing these changes will be committed 
within a day or two...

-kai



---------------

For the afficionados here's a more explicit version of the above example 
code without the shortcuts to the shortcuts:

    RecordQuery q = new RecordQuery();
    q.addOperatorCondition(Query.Binary.AND, ForumRecord.OWNER, 
Query.Operator.EQUAL, owner);
    q.addOperatorCondition(Query.Binary.AND, ForumRecord.CATEGORY, 
Query.Operator.EQUAL, category);
    q.addOrderBy(Query.Order.ASCENDING, ForumRecord.FORUM_NAME);
    RecordList list = query(q);

Q: How does this Query know which project I'm running?
A: This piece of sample code is what would be written within an Action. 
the 'query(q)' method passes your Query to the Action superclass. This 
superclass knows which project your Action implementation is tied to, 
and will add or forcefully replace the project ID number for any record 
you are querying.

Q: How does this Query know which tables I'm querying?
A: Forget about tables. It is true that when you're developping Record 
classes, you have to think about organizing your data in sections as if 
they where in different tables (Record Classes) for efficiency purposes. 
The RecordQuery, and how it executes in an Action makes a point of 
blurring the line between tables. The DataAdapter will automatically 
figure out how to join SQL tables over their ID numbers.  Stop thinking 
about tables, start thinking about Records, in the way that Java thinks 
of Object from a variety of Classes.

Q: How do I do a Query that spans multiple Records?
A: Let's say you want to execute a Query for ForumPostRecord's in all 
ForumRecord's that were created by a certain PersonRecord whose ID 
number is a variable personId.

   RecordQuery q = new RecordQuery();
   q.addOp(ForumPostRecord.class); // set the type of Record you want to 
retrieve.
   q.addOp(ForumPostRecord.OWNER, ForumRecord.RECORD_ID); // link owner 
ID to a record
   OperatorCondition oc = new OperatorConditon(PersonRecord.RECORD_ID, 
personId); // find PersonRecord with the given ID
   q.addOp(ForumPostRecord.POSTER, oc); // link personId to the POSTER 
field.
  
Q: How do I run queries over multiple types of Records?
A: Queries can be executed over Records that have been inherited, and 
the query's result will allow you to get a mixed set. For example, 
consider your project has AdminPersonRecord's and ClientPersonRecord's, 
that both inherit from the PersonRecord. To make it simple, Clients have 
a credit card number field, and Admin's have a mailbox number field, 
where they payment checks go to. Your action wants to query all 
PersonRecord's for a login name, All you have to do is run your query on 
the PersonRecord instead of the ClientPersonRecord or the AdminPersonRecord:

  q.addOp(PersonRecord.LOGIN, searchLogin);
  RecordList list = executeQuery(q);

The RecordList object, once you load them fully with the loadRecords() 
method or the like, will give you a heterogenous Collection of Records:

  Collection<Record> records = loadRecords(list);
  for (Record r : records) {
     if (r instanceof (ClientPersonRecord)) {
        [...]
     } else if (r instanceof (AdminPersonRecord)) {
        [...]
     }
  }

Re: [Nectar-devel] Licensing of the base distribution...

[Royce A. <124...@cs...>]

I don't see not including MySQL support Nectar as a huge problem as I plan
to implement some better database system in the future anyways (native to
nectar =D).  POstGreSQL is fine anyways, if a little slow...But we have
record caching (and soon query caching) so that's not a huge issue for
small sites/serving needs.

On another note - being the rebellious bugger that I am, I'm rewriting the
query and record system to be what I call better - expect updates/approval
requests sometime soon...

--ROyce


> Extract from previous emails not posted to the list:
>
> --------------------------------------------------------------
>
>     The other topic is choosing the right license for the base
>     distribution of Nectar. Fundamental to this is a business concept
>     behind Nectar, which even if we don't want to make any money from
>     the project, we should have some form of business plan to at least
>     promote the use of the system.
>
>     I would like these things to be in that license:
>
>     1. using an open source model
>     2. allowing proprietary code to link with Nectar
>     3. somehow make money from commercial, for-profit users, ie
>     e-commerce or paid hosting.
>
>     The problem is that the Open Source Definition
>     (http://opensource.org/docs/definition.php) states in Article 6:
>
>          6. No Discrimination Against Fields of Endeavor
>
>     The license must not restrict anyone from making use of the program
>     in a specific field of endeavor. For example, it may not restrict
>     the program from being used in a business, or from being used for
>     genetic research.
>
>        /*Rationale:* The major intention of this clause is to prohibit
>        license traps that prevent open source from being used
> commercially.
>        We want commercial users to join our community, not feel excluded
>        from it./
>
>     so goal #1 and #3 are in conflict.
>
>     One option would be to keep all the clustering code totally
>     proprietary, or even code that allows for multiple projects (though
>     that would be *very* difficult). The problem here is of course that
>     since we're using an open source model, we can't prevent anyone from
>     writing a clone of our clustering software.
>
>     So that doesn't really work either...
>
>     What we could consider is a not-so-open license which would only
>     restrict commercial users (which really isn't very different from
>     what MySQL and Trolltech are doing, they're just using a different
>     approach!).
>
>     The final option is to adopt a license policy similar to MySQL /
>     Trolltech. Release Nectar in GPL, and make anyone that wants to
>     release proprietary code that uses Nectar pay us... This is a really
>     bad option for us I believe, because it would drive away a massive
>     amount of potential users, and the competition is rough...
>
>     My initial "dream" was to build a not-for-profit organization
>     (association) that would, with it's income, pay developpers and
>     project managers. Why not a corporation? cause I don't like the
>     tyrannical structure of corps... in an association, the body of
>     members (including package developpers paying a membership fee)
>     would vote on key positions in the association and on important
>     decisions. Package developpers and any other financial contributors
>     would essential become similar to the share holders, who would get
>     their value not in return from investment, but in a better end
>     product. In a corporate world, it would be the founders / owners /
>     investors who would collect the profit, which then would be
>     financial and not necessarily a better product.
>
>     So, yeah... I'm trying to keep away from the evil corporate world.
>     But because of Article 6 in the OS definition, the 'soft' business
>     plan crumbles, and we'd have to use a non OSS license, making us
>     evil anyway... :(
>
>     But not all is lost...
>
>     Let's stop thinking about software as a product, but rather as a
>     service. Nectar specifically, is much more of a service than a
> product.
>
>     So where do we make the cash?
>
>     Hosting. :)
>
>     We could go fully LGPL (as long as MySQL isn't gonna be a pain) and
>     focus a business model on a server hosting business.  We'd focus on
>     tuning the servers just right and we'd provide support to project /
>     package developpers. If another hosting company wants to start
>     hosting Nectar projects as well, they can take the source code and
>     try, but they wouldn't have the system expertise that we would, nor
>     many tools that we would keep inhouse...
>
>     This hosting concept doesn't lend itself too well to a
>     non-profit-organization, but it's quite possible a hybrid could be
>     found, or even just a partnership (ie, a corporation would provide
>     hosting and subcontract tech support to the non-profit org, which
>     would actually for a "repeatable process" (ARGGGHH get SE out of my
>     head)). These contracts would then provide the funding for
>     development efforts within the org...
>
> --------------------------------------------------------------
>
>
>
> Now here's the problem... I just received an email from MySQL licensing
> / sales department:
>
>>> I'm leaning for LGPL because I want to allow others
>>> to develop and run proprietary code on this platform,
>>> which would mean that their code would link to the
>>> LGPL base code. Their software would then run on
>>> a shared server cluster, running potentially hundreds
>>> of different proprietary software bits from different developpers.
>>>
>>> So, in short... Proprietary code links to my LGPL code
>>> which links to GPL MySQL... What happens to MySQL's
>>> licensing policy?
>>
>>
>
> From
> http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL
> =======
> If a library is released under the GPL (not the LGPL), does that mean that
> any program which uses it has to be under the GPL?
>
> Yes, because the program as it is actually run includes the library.
> =======
>
> => So your "LGPL" would need to be GPL'ed, thus
> forcing your proprietary code to be GPL'ed as well.
>
>
>>> If that means a commercial license is required, who needs
>>> to buy it? Each developper of each proprietary bit of code or
>>> just me, the developer of the base distribution?
>>
>>
>
> In that case you should purchase right to distribute
> the commercial MySQL client libraries with your
> programs. And this requirement would rely on
> your shoulder, as you are the person, in whose
> interests it is to ensure, you are GPL compliant.
>
> Good additional reading is available at
> http://www.fsf.org/licensing/licenses/lgpl-java.html
>
>
>>> Furthermore, a single server may run a large number of projects,
>>> but not all will use MySQL (other data adapters may be available).
>>> Consider one developper has written proprietary code that indirectly
>>> links to MySQL code, but doesn't use it... Does he also need a
>>> license?!?
>>>
>>> Or is this all a moot point because LGPL code isn't allowed to link
>>> to GPL code?
>>
>>
>
> If you want to make sure, you can create your own
> drivers in LGPL, you must get commercial MySQL
> Client libraries to "cut" the link to the GPL server
> or purchase commercial MySQL Server to be run
> beneath the system (and the licenses are really
> cheap: 250 Euro/server for MySQL Classic and
> 500 Euro/server for MySQL Pro).
>
>
>
> In short, this means that Nectar can't include the MySQL Connector J
> driver (necessary to access a MySQL server) in the distribution unless
> Nectar is itself GPL. Nectar will still have MySQL support (or more
> generally, SQL support), but will ship without the MySQL driver. It will
> be up to the end user, if they want to use MySQL, to buy a Commercial
> server license from MySQL.
>
> In order to use MySQL freely, Nectar would have to be GPL, which in turn
> would prevent anyone from developping proprietary code for Nectar
> entirely (even if they bought the MySQL license then, Nectar would still
> be GPL).
>
> So MySQL is one problem and can be easily circumvented, simply by
> shipping Nectar with a Postgresql driver instead of MySQL, which comes
> under the BSD license, which isn't 'viral' like GPL. The
> MysqlDataAdapter implementation will remain in the base distribution,
> because it doesn't link statically to any MySQL code, it only links at
> runtime if the driver .jar file is available.
>
> The MySQL driver is currently the only "offender" in Nectar, the only
> piece of software that Nectar uses that is GPL.
>
>
> Now... Nectar heavily relies on a lot of Apache Foundation projects,
> especially Jakarta Commons and Struts. Some parts of Nectar are actually
> modified source code from a variety of different Struts releases. All
> this code is under the Apache License, which makes no restriction to
> being linked with proprietary code, but the license doesn't allow people
> to take code, modify it and release it under another license.
>
> In essence, this would mean that if Nectar would be released in LGPL,
> some parts of it would have to come under the Apache License, which is
> just really confusing and messy... Since there is no real reason I can
> find why the LGPL is any better than the Apache License, we may as well
> use the Apache License for the whole of the base distribution.
>
> Soooo... that's that... If there are no complaints or unless someone has
> suggestions, the next release of Nectar (not coming anytime soon just
> yet) will be under the Apache License, version 2.0, and will not include
> MySQL support directly! (http://www.apache.org/licenses/LICENSE-2.0)
>
> Then there's the matter of finding a good license for the sample code,
> which should be an open source license that actually allows anyone to
> take the code and use under any other license, proprietary or not, but
> that'll be in another mail :)
>
> -kai
>
>
>
>
>
> !DSPAM:426e2c2a157331858919272!
>

[Nectar-devel] Licensing of the base distribution...

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

Extract from previous emails not posted to the list:

--------------------------------------------------------------

    The other topic is choosing the right license for the base
    distribution of Nectar. Fundamental to this is a business concept
    behind Nectar, which even if we don't want to make any money from
    the project, we should have some form of business plan to at least
    promote the use of the system.

    I would like these things to be in that license:

    1. using an open source model
    2. allowing proprietary code to link with Nectar
    3. somehow make money from commercial, for-profit users, ie
    e-commerce or paid hosting.

    The problem is that the Open Source Definition
    (http://opensource.org/docs/definition.php) states in Article 6:

         6. No Discrimination Against Fields of Endeavor

    The license must not restrict anyone from making use of the program
    in a specific field of endeavor. For example, it may not restrict
    the program from being used in a business, or from being used for
    genetic research.

       /*Rationale:* The major intention of this clause is to prohibit
       license traps that prevent open source from being used commercially.
       We want commercial users to join our community, not feel excluded
       from it./

    so goal #1 and #3 are in conflict.

    One option would be to keep all the clustering code totally
    proprietary, or even code that allows for multiple projects (though
    that would be *very* difficult). The problem here is of course that
    since we're using an open source model, we can't prevent anyone from
    writing a clone of our clustering software.

    So that doesn't really work either...

    What we could consider is a not-so-open license which would only
    restrict commercial users (which really isn't very different from
    what MySQL and Trolltech are doing, they're just using a different
    approach!).

    The final option is to adopt a license policy similar to MySQL /
    Trolltech. Release Nectar in GPL, and make anyone that wants to
    release proprietary code that uses Nectar pay us... This is a really
    bad option for us I believe, because it would drive away a massive
    amount of potential users, and the competition is rough...

    My initial "dream" was to build a not-for-profit organization
    (association) that would, with it's income, pay developpers and
    project managers. Why not a corporation? cause I don't like the
    tyrannical structure of corps... in an association, the body of
    members (including package developpers paying a membership fee)
    would vote on key positions in the association and on important
    decisions. Package developpers and any other financial contributors
    would essential become similar to the share holders, who would get
    their value not in return from investment, but in a better end
    product. In a corporate world, it would be the founders / owners /
    investors who would collect the profit, which then would be
    financial and not necessarily a better product.

    So, yeah... I'm trying to keep away from the evil corporate world.
    But because of Article 6 in the OS definition, the 'soft' business
    plan crumbles, and we'd have to use a non OSS license, making us
    evil anyway... :(

    But not all is lost...

    Let's stop thinking about software as a product, but rather as a
    service. Nectar specifically, is much more of a service than a product.

    So where do we make the cash?

    Hosting. :)

    We could go fully LGPL (as long as MySQL isn't gonna be a pain) and
    focus a business model on a server hosting business.  We'd focus on
    tuning the servers just right and we'd provide support to project /
    package developpers. If another hosting company wants to start
    hosting Nectar projects as well, they can take the source code and
    try, but they wouldn't have the system expertise that we would, nor
    many tools that we would keep inhouse...

    This hosting concept doesn't lend itself too well to a
    non-profit-organization, but it's quite possible a hybrid could be
    found, or even just a partnership (ie, a corporation would provide
    hosting and subcontract tech support to the non-profit org, which
    would actually for a "repeatable process" (ARGGGHH get SE out of my
    head)). These contracts would then provide the funding for
    development efforts within the org...

--------------------------------------------------------------



Now here's the problem... I just received an email from MySQL licensing 
/ sales department:

>> I'm leaning for LGPL because I want to allow others 
>> to develop and run proprietary code on this platform, 
>> which would mean that their code would link to the 
>> LGPL base code. Their software would then run on 
>> a shared server cluster, running potentially hundreds 
>> of different proprietary software bits from different developpers. 
>>
>> So, in short... Proprietary code links to my LGPL code 
>> which links to GPL MySQL... What happens to MySQL's 
>> licensing policy?
>    
>

From
http://www.fsf.org/licensing/licenses/gpl-faq.html#IfLibraryIsGPL
=======
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL?

Yes, because the program as it is actually run includes the library.
=======

=> So your "LGPL" would need to be GPL'ed, thus
forcing your proprietary code to be GPL'ed as well.
  

>> If that means a commercial license is required, who needs 
>> to buy it? Each developper of each proprietary bit of code or 
>> just me, the developer of the base distribution?
>    
>

In that case you should purchase right to distribute
the commercial MySQL client libraries with your
programs. And this requirement would rely on
your shoulder, as you are the person, in whose
interests it is to ensure, you are GPL compliant.

Good additional reading is available at
http://www.fsf.org/licensing/licenses/lgpl-java.html
  

>> Furthermore, a single server may run a large number of projects, 
>> but not all will use MySQL (other data adapters may be available). 
>> Consider one developper has written proprietary code that indirectly 
>> links to MySQL code, but doesn't use it... Does he also need a license?!?
>>
>> Or is this all a moot point because LGPL code isn't allowed to link 
>> to GPL code?
>    
>

If you want to make sure, you can create your own 
drivers in LGPL, you must get commercial MySQL
Client libraries to "cut" the link to the GPL server
or purchase commercial MySQL Server to be run
beneath the system (and the licenses are really
cheap: 250 Euro/server for MySQL Classic and
500 Euro/server for MySQL Pro).

  

In short, this means that Nectar can't include the MySQL Connector J 
driver (necessary to access a MySQL server) in the distribution unless 
Nectar is itself GPL. Nectar will still have MySQL support (or more 
generally, SQL support), but will ship without the MySQL driver. It will 
be up to the end user, if they want to use MySQL, to buy a Commercial 
server license from MySQL.

In order to use MySQL freely, Nectar would have to be GPL, which in turn 
would prevent anyone from developping proprietary code for Nectar 
entirely (even if they bought the MySQL license then, Nectar would still 
be GPL).

So MySQL is one problem and can be easily circumvented, simply by 
shipping Nectar with a Postgresql driver instead of MySQL, which comes 
under the BSD license, which isn't 'viral' like GPL. The 
MysqlDataAdapter implementation will remain in the base distribution, 
because it doesn't link statically to any MySQL code, it only links at 
runtime if the driver .jar file is available.

The MySQL driver is currently the only "offender" in Nectar, the only 
piece of software that Nectar uses that is GPL.


Now... Nectar heavily relies on a lot of Apache Foundation projects, 
especially Jakarta Commons and Struts. Some parts of Nectar are actually 
modified source code from a variety of different Struts releases. All 
this code is under the Apache License, which makes no restriction to 
being linked with proprietary code, but the license doesn't allow people 
to take code, modify it and release it under another license.

In essence, this would mean that if Nectar would be released in LGPL, 
some parts of it would have to come under the Apache License, which is 
just really confusing and messy... Since there is no real reason I can 
find why the LGPL is any better than the Apache License, we may as well 
use the Apache License for the whole of the base distribution.

Soooo... that's that... If there are no complaints or unless someone has 
suggestions, the next release of Nectar (not coming anytime soon just 
yet) will be under the Apache License, version 2.0, and will not include 
MySQL support directly! (http://www.apache.org/licenses/LICENSE-2.0)

Then there's the matter of finding a good license for the sample code, 
which should be an open source license that actually allows anyone to 
take the code and use under any other license, proprietary or not, but 
that'll be in another mail :)

-kai

[Nectar-devel] mailing list traffic increase...

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

hello subscribers...

just wanna give you a little warning that the traffic on this list may 
increase soon, as I'm going to start sending the communication that I 
usually just spam Royce with to this list... it's going to be a lot of 
very small status updates or endless rants about something pretty 
specific... may be interesting, but probably won't be :P

No harm, no foul if you don't want to receive all this spam, you can 
unsubscribe using the links below (or at 
http://lists.sourceforge.net/lists/listinfo/nectar-devel ) at any time. 
If you can't unregister yourself for any reason, please let me know, 
I'll do my best to remove you :)

If you want to receive regular updates about the progress of nectar, but 
not want to participate in the developer's talk, you can also join the 
nectar-announce list at 
http://lists.sourceforge.net/lists/listinfo/nectar-announce .

Of course, you're welcome to stay, and more importantly, you're very 
welcome to participate in the updating and ranting! ;)

-kai

[Nectar-devel] Nectar WebServices Project Status Update

[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.

[Nectar-devel] Mailing List is now public :)

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

Hi guys,

I set this mailing list to public again, so anyone may subscribe to it. 
Archives of this mailing list will now be kept on sourceforge.net

-kai

[Nectar-devel] Mailing List

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

Hi,

nec...@li... was a list for development =
communication for the project, there were a few people subscribed but =
they never mailed anything, so I booted them :)

Our whole group is on this list, no one else, so please use this list to =
spam related messages!

-kai

[Nectar-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Nectar-devel] Nectar WebServices Dev update

[Kai S. <sk...@sk...>]

Hi,

Just to let you know what I've been working on, I'll try to omit the =
gory details...

These past two weeks, I've mainly worked on getting an encrypted and =
compressed network communication link going between a GUI client and the =
Servlet, which can transport Action objects (ie, commands) and their =
response objects after they have been executed. I've really had to =
wrestle with countless bugs, ripping my hair out...  But tonite, =
everything seems to work stably and effeciently, so I can finally move =
on to something else.=20

I've written everything so that the GUI client actually loads pretty =
much all it's GUI elements and action definitions from the server, so =
that when you install the client, you only really install a very basic =
set of software, which connects to the server and downloads all the =
plug-ins that actually make the client work. This mechanism, which is =
really an auto-update tool, isn't written yet, but it's fully in the =
range of capabilities of the current code...

Next up is a proper Authentication service to protect records from =
unallowed access and editing, then probably making that auto-update =
thing. Both of these tasks can take a lot of time. Also, editing and =
creating records is only half written and not at all tested, but that =
shouldn't be long. After that, I'll really only have the views for the =
various front-end pages and elements to write, and the GUI elements for =
the admin client, which is a lot of work, but it's duration is very =
predictable, as it's pretty straightforward and easy coding (unlike this =
**** thing I've been working on for the past two weeks almost!).

Btw, the admin client is "code-named" Reda. I don't precisely remember =
why I chose that ugly name, but it was the only acronym I could assemble =
at the time. Don't ask what it stands for... I don't really remember...

-kai

--------------------------------------------------------
Kai Schutte sk...@sk...
Developer - Nectar WebServices
http://sourceforge.net/projects/nectar/