Re: [Flaim-users] language bindings, debian packages, project obscurity

[Daniel S. <dsa...@no...>]

Jeff,
 
I don't know why the Perl bindings cannot be managed via CPAN - sounds like a good idea to me.  Only things that get checked back into our source tree would need copyright assignment back to Novell.
 
Regarding Java - should not be required to build xflaim.  The Makefile looks for JAVA_HOME in the environment.  If it is missing, it should skip all of the Java build stuff.  Perhaps we have a bug in the Makefile.
 
The documentation links from the FLAIM wiki page (http://developer.novell.com/wiki/index.php/Flaim) are now correct, but the links from the main project page are still incorrect.  Unfortunately, I cannot change those directly myself - we are working with the IT people to get them changed or eliminated.  I think that IT meant to phase them out in favor of the wiki site, but they aren't completely done with it yet.
 
You are reading correctly that flaim concurrency is entirely by way of threads within a single process.  Only one process can work on the database at a time.  This tends to be very good for applications that are servers (like Novell's eDirectory).  A server is a good solution for providing "multi-process" concurrent access - but nobody has ever written just a plain old "flaim server".  By embedding FLAIM in a server process, you get all of the features that will make a multi-threaded server process scale well - particularly caching.  But caching is also what makes it difficult for multiple processes to simultaneously have direct access to the database.  If each process has its own cache, those caches would have to be kept in sync.  If there were a shared cache between processes, there are other complications to deal with.  Suffice it to say, our current position is that if you need multi-process concurrent access, you will need to implement some kind of server that other processes talk to via protocol.
 
- Daniel Sanders

>>> "Jeffrey W. Baker" <jw...@ac...> 8/17/2006 1:16 AM >>>
On Wed, 2006-08-16 at 13:23 -0600, Daniel Sanders wrote:
> Jeffrey,
>  
> Thank you for your interest in the FLAIM project.  Sorry about the
> difficulty in finding it.  We agree that its relative obscurity is a
> problem.  We are going to look at some things to get it more
> visibility in the search engines.
>  
> We would welcome your participation in the project.  Nobody is
> currently working on Perl bindings, so that is a great place to
> contribute.

C++ makes this project a bit larger than it would be if flaim were
implemented in C, but it can probably be done within our lifetimes :)

> We are planning on creating Debian packages - just haven't got to it
> yet.  Any pointers or help you would like to give us on that would
> also be welcome.

xflaim builds and tests on all of ubuntu 6.06 x86_64, ubuntu 6.06 ppc32,
debian 3.1 x86_64, and debian 3.1 x86, so I don't forsee a big problem
here.  Note that I'm not one of those Debian developer in-crowd type of
people.  But I think I can get the packages built.  Ubuntu requires
fewer secret handshakes than Debian, so that will probably be the first
people to accept the packages.  For Ubuntu Universe repository there are
hardly any requirements at all.

On the build side, there are a few hitches.  I didn't get any shlibs out
of a 'make test' and 'make libs' fails by way of not finding Java.  Java
is not exactly Free in that tricky DFSG sense (and there's no real Java
solution for ppc32 Linux), so I will likely try to strip out the java
build target temporarily.

> As with many open source projects, Novell's policy for projects it
> sponsors is to have contributors assign copyright back to Novell.  I
> hope that isn't a problem.  Of course, all contributions will be made
> available under the GPL (FLAIM's current licence).

Can the Perl bindings be managed through CPAN?  That would be the
canonical Perl way, and it will spread adoption.  Every platform that
has Perl also has CPAN, whereas many platforms do not have organized
package libraries like the one Debian provides.

As for the Debian packaging, you would probably want to keep that
separate also.  Because there is a certain impedance mismatch between
the flaim build process and the usual gnu autotools build, I think
you'll find it's best to keep that upstream (that's you) blissfully
unaware of the Debian sausage making.

If I make any actual changes on the flaim tree, I'll be pleased to
assign those copyrights back to Novell.

> If you need help using the FLAIM APIs, please let us know.  We would
> be glad to assist you as our time allows.

The links to the documentation from Novell Forge lead to non-existent
pages, but the links from the Bandit project work.  Maybe fix the links
on Forge, or maybe consolidate under the Bandit wiki?

[helpful descriptions of flaim and xflaim elided]

Just to confirm that I'm reading this correctly, is flaim concurrency
entirely by way of threads within a single process?  The way I read it,
only one process can work on the database at a time.

-Jeff Baker