Re: ITP: debian-corba -- Suite of tools for using the Debian CORBA interface
On Fri, 2002-02-08 at 04:29, enrico.sirola@riskmap.net wrote:
> wow! this seems to be cool!!
I'm glad you're interested too; working on this is a lot of fun :)
> I just took a look at http://cvs.verbum.org/debian/debian-corba
> and would like to help. I have a good experience on CORBA with OmniORB
> and Python/c++.
> Let me know if I could help in some way.
Things are evolving *very* fast. If you have some experience in
designing IDL interfaces, and you're familiar with how the Debian
project is organized, any comments on the interface structure would be
quite helpful. Keep in mind that it should be designed for speed first,
since I intend to make this the backend to most of the project's various
frontends, like the {packages,buildd,qa}.debian.org webpages, the
bugscan script posted to -devel-announce, possibly aj's testing scripts
(we could weight packages by popularity! :) ), etc.
I still haven't written the interface to db.debian.org; doing that would
be very helpful. And an interface to lintian.debian.org would be cool,
too. Then it would be trivial to write a script/GNOME app/webpage which
would display packages with the most lintian errors, showing their open
bugs, what architectures they're built on...anything.
Also, a whole huge area to tackle is security. For example, I'd like to
have a CORBA nameserver running on master.debian.org, which would then
be able to tell clients where the various servers (PopularityServer,
ArchiveServer, etc.) are. The problem with this is that by default,
anybody can bind or unbind names in the Naming Service. I haven't
looked too much into the CORBA Security Service yet, so I'm not sure if
that would be the solution. Or maybe orbit-name-server has a way to
make things read-only past a certain point.
Another thing that desperately needs fixing is the postgres queries in
the ftpmaster.py implementation. For every binary package, it makes a
query to see what suites it is in. This is way way slow, but I'm not
sure how to do it better. To solve this problem, you will need to be
familiar with the layout of the projectB database on auric. I've put a
fairly recent dump here:
http://web.verbum.org/~walters/debian/projectb-dump
The bug servant implementation needs work to update it to the new way
bugs are indexed; you'll have to coordinate with the bugs.debian.org
maintainer; let me know if you want to do this one, and I'll put you in
touch with him.
Also, it would be great if someone could hack on packages.cgi; this
could use a great deal of beautification and more features.
Incidentally, I've put up a demo of packages.cgi, now with
PopularityServer integration, at:
http://monk.debian.net/packages
Be patient if it seems slow; those postgres queries *REALLY* need
optimization; it's not CORBA or anything else that's slowing it down.
Because of this, I've limited the MaxClients to 7.
Anyways, there are like ten billion things to do, so pick one and send
me patches! :)
Reply to: