Here are some projects in no particular order (except the 1st one):
* PORT THE MODS FROM RELEASE BRANCH TO DEVEL TRUNK
This is one for Kevin and me. Others are of course more than
wellcome :-)
* INCREMENTAL TELL
the lack of it means that when unifying datastructures containing
futures we will retain the entire datastructures until all futures
have been bound (with streams, this means for ever).
I prototyped a version of incremental tell before, so I suppose I
could take care of this.
* 64 BIT CLEANUP
with Intel delaying their plans for 64 bit, this item is less urgent
than it once seemed. However, there are 64 bit architectures and
people have tried (of course unsuccessfully) to build Mozart on
them. Another advantage would be to make the system more robust by
removing implicit assumptions.
* DLL ISSUES, SYMBOL EXPORTS, ETC
we need to resolve the issues with DLLs on Windows and we need to
make it more practical to build extension libraries for Mozart. In
particular this means exporting more symbols and more APIs (for
example, there is no way to reuse Oz propagators in 3rd party native
functors)
* REORGANIZATION
the configure/build system has become too complicated to manage
sanely. Leif and I have discussed it and we would like to see a
reorganization into a _staged_ build, starting with a minimal core
system. Libraries and tools should then be built using ozmake or
something like it from a partial install. contrib must go (real
contribs need to be maintained and made available separately).
* SECURITY
We need to make it possible to execute untrusted applications and to
compile untrusted code (there is currently no security with
"prepare" sections in functors). Mozart intended to address
security issues through module managers, but did not follow
through. We should do this now. I do not wish to entertain
alternative approaches to security; that's interesting too, but we
should first try to make module managers practical for their
intended purpose, and learn from the experience.
* SYSTEM THREADS
We need an interface for system threads so that we can have
e.g. native services servicing potentially blocking requests.
I did a prototype for this too.
* CONSTRAINTS
I am glad that Christian is back in the game. Indeed we need to
improve things; e.g., while this is not my area of expertise, I
understand that scheduling support is showing its age. Personally,
I'd like to get back into improving/developing set/selection/tree/graph
constraints. I'd like to see propagator priorities or something
like that to help achieve reasonable staged propagation.
* REVAMP THE WEB SITE
I think this is important because it is the face that we present to
the world. I'd like a visitor to be able to find out quickly what's
currently going on with Mozart (not just with us, but also in the
user community). I think that the web site needs to _feel_ dynamic
because that will also be the perception for Mozart itself.
Christian mentioned the publication database; I'd like to accomodate
publications not by us. I have mentioned teaching material before
too. etc...
* DOCUMENTATION
ozdoc is showing its age. Nowadays we should adopt the XML/XSLT
combo. I have some preliminary bindings for libxml2/libxslt which
we can use as the foundation of a more modern ozdoc.
Cheers,
-- Dr. Denys Duchier Équipe Calligramme LORIA, Nancy, FRANCE - Please send submissions to hackers@mozart-oz.org and administriva mail to hackers-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/.