#musicbrainz

database dumps need to also be marked with the same version numbers.

yup!

and dumped in lock-set.

get los und kipp ins bett!

yes

:-)

nacht!

'kippt gleich aus den latschen' has to be one of the better german idioms.

djce!

how goes it?

better

nothing went wrong today :-)

good.

:-)

how is the car?

Well, still with me and still driveable.

good.

could be worse.

next week the insurance people take it off me for a while to inspect it.

:-(

Maybe you can help me.

I have a friend who can't log into read his mail.

The jury's still out on whether I get a courtesy car or not.

shoot

works sometimes not others.

so I watched maillog as he logged in

pop3?

I got a 'lost mailbox lock' message when he logged.

imapd

oh ruaok

I know just about zip about imap

i started works on a wrapper for vb

blake is now known as sbw

sorry ruaok I'm not sure I can help with that

I was wondering about where the lock files may be.

ok.

WhiteDog: cool.

just a noobish c question :)

those .h files

do i need to add them as well

ruaok: for pop3 it would typically be /var/spool/mail/ IIRC

or are they in the dll already

and if they're not

what is in the dll then? :p

djce: yeah, I've done a find on all of /var and no go.

I'll ask Kevin -- he should know.

Thanks though.

.h files give definitions and prototypes for classes and functions to the compiler.

So the contents of .h file don't go into a DLL (per se).

the only header file you need to really worry about is queries.h

That defines the queries that a VB program can make via libmb.

Those definitions need to be available to a VB programmer.

ok :)

djce: johan has made a server available for our use in Delft.

ooh

nice

Got plans?

So....

of course!

yalaforge and I have hashed out a diabolical plan to test replication between him and I.

So test.mb.org will be mirroring off his machine in a replication test.

I will work on the server side replication stuff later today, in hopes to get it ready so that we can roll it out on the main server soon.

If the main server can start kicking out the replication data, we should be able to make the delft server a test replicant.

for a longer term test to make sure everything works.

how is that for a plan?

So the data will flow zim => delft => grunt?

or you mean test.mb.org == delft?

There are two phases:

1. Test the replication on the server side, For that we have yalaforge => test.

Once we're happy with that, we roll out replication on zim.

then

2. zim => delft, zim => grunt

with the understanding that the replication packets may get invaladidated at any point during the test.

ok, fair enough

how close is the code right now?

the core code that manages the internal replication tables and the code that creates the database dumps is in pretty good shape.

Is the make-dump code tied in to the Export code?

on the replicant side, the code that takes a dumpfile and imports it is also in good shape.

so that the exports can tie in with replication packet boundaries?

the code that sticks the file on the ftp site/grabs it from the ftp side is largely non-existant.

no, that has not been addressed.

well, that sounds trivial. no matter.

ok

However, each of these scripts could use your careful eye to spot problems.

I plan to go in and look at the replication stuff tonight and make sure its up to snuff.

verify all my assumptions and write an XML dump script that yalaforge can use to populate the lucene search index.

no you lost me there - how does this tie in with lucene?

after that, if you could examine the server replication portions and give it a your seal of approval for the next server release, that would be awesome.

yalaforge and I have been thinking about how to update the lucene index from the DB.

The requirements are to fit in with our replication scheme and hopefully be indenpendent enough so that one could create a lucene index server, without actually requireing a postgres install.

The latter requirement makes for an excellently scalable system.

We could add more index servers as we need them. Or as the album tagger userbase grows...

So, to update the lucene index while people are using the index is tricky.

Thus yalaforge has come up with a shadow index scheme. We keep two indexed around at any one time.

One to serve queries and one that is being updated behind the scenes.

interesting...

then when an update has been applied to the shadow index, the two indexes rotate.

The update packets that need to be applied to the lucene index, are derived from the Replication data we already collect on the server.

so during the replication phase on the server, we will create a DB dump file for the table and an XML lucence update packet.

any lucene index grabs that from the FTP site and updates its shadow index and then switches the indexes out.

Does that make sense?

It seems overly complicated at first, but the amazing flexiblity we derive from it will make us glad later.

sounds interesting. That all sounds good, if lucene makes us do that.

to avoid various IPC issues that yalaforge and I have discussed, this seems like the best approach.

In the end the web site will do searches via making corba queries to the index server.

since the index server runs on java and we run on perl, yalaforge decided that corba is the fastest way to couple the two.

are we hitting acronym overload yet? :-)

How much of this is theory so far?

the lucene index server is getting there.

I've seen a test that builds indexes and accepts queries at the same time.

the replication stuff is theory right now.

yalaforge has created a DTD/xml example for the lucene replication stuff.

We had agreed to have this stuff finished in about 7 more weeks time.

yalaforge has another exam next week, so he won't be doing much.

But after that we will work on it more -- and so far he is making great progress.

fair enough. good luck yalaforge :-)

I have faith -- he is a very smart cookie.

great. You guys have been busy

indeed.

have you looked at the tagger?

cannot convert parameter 2 from 'int' to 'int *'

any help? :D

you need to pass in a pointer to an int, not an int

int foo;

NOT: function(foo)

BUT: function($foo)

er

BUT: function(&foo)

(the $ was a typo, sorry)

oh :P

ok :)

ruaok: no luck yet. I haven't worked out how to install the py-mb stuff

download the bindings

then sudo python setup.py install

and that installs the libmb python bindings

ImportError: No module named distutils.core

you need to install python2.3-dev

ok

thought it might be that... that was my next guess

ImportError: No module named ctypes

ohh, you got icepick's new implementation of the bindings.

either back off one version, or install the ctypes python lib.