Three Google Summer of Code ideas

I may end up doing some of these myself, but I'd like to put them out
there for discussion.

1) Have an embeddable svnserve. Today, I was writing a Java servlet
that forked a svnserve process. The Java servlet exposes a ICE (CORBA
like) API for remote clients. The servlet uses the Subversion
filesystem under the hood to have a versioned database, but the clients
of the servlet don't know that. They see a very-non Subversion like API.

Instead of dealing with the issues of starting and stopping a child
process in Java, it would be cool to abstract out the code in svnserve
so that anybody could embed svnserve protocol svn server in their own code.

No telling where svnserve's may start showing up if they are very easy
to embed and make a Subversion repository networkable

2) It would be interesting to use the open source ICE project as a
transport. ICE is extremely fast RPC mechanism that provides. This one
would be more fun and it would be interesting to have a client bind
directly to the server APIs, skipping.

This would also require writing a C++ API to wrap the C code, since I
only deals in C++.

In ICE you write an IDL like file:

module Subversion {
   struct Revision { ... }
   struct Info { ... }
   struct DirEntry { ... }
   sequence<DirEntry> DirEntries;
   Interface {
     Info info(string URL, Revision rev);
     DirEntries list(string URL, Revision);
   };
}

This then compiles down into C++, Java, code, or in Python or Ruby's
case, you can load this file in the script and have it dynamically
generate the classes and objects without any C++ bindings to write.
It's very cool.

You then just use them as local objects, but of course, they are doing
RPCs over the hood.

3) Come up with a common Subversion objected oriented abstraction for
all bindings. I think we spoke about this at the summit. Comments were
made that the Ruby bindings were the best designed.

Instead of having each binding have thier own OO feel, they all
implement the same feel.

This isn't too codey, and may not make a good SOC project.

Let me know if these would be appropriate and I can put them up in the
project_tasks.html page.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org