[Gnu-arch-users] Smart server question

[Szilard Hajba]

Hi!

I've read some messages from the archive about this projekt, but the last
message in the area was more than a year ago. Have anything happened in the
subject?

In my opinion ARCH really lacks a smart server. I have recently started one
project with ARCH. It was not really a start, I converted it from CVS.
Since than I often used to measure the network load during operations.

I write some observations and then I write some suggestions.

Normal everyday operations (commit, update) are working fine. This don't need
too much improvement, it's much better than CVS with "smart server" :)

But there are some commands that work on the archive, what are extremly slow.
I have made about 20 tags on my imported project. The creation of the first
tag held about 5 minutes (!) and transferred several megabytes from the
server. The remaining 19 tags held about 1 second (after I ssh0ed to the
server and run the tag commands locally :)

An other example is cacherev. If I want to make a cached revision on the
server it's much faster locally than on a slow network.

Now the suggestions:

As I read the archives I noticed that you had several discussions about smart
servers but as I know there is no usable solutions.

1. suggestion: Why don't you make the transport layer pluginable!
        You need a well defined API (You have az abstract filesystem layer
        that would be good for a base) and the capability to load plugins that
        implement a new transport layer. Than it would be easier (for me, for
        example) to create a smart server.

If it would be possible to develop several transport layers and they would be
usable with your standard tla distribution than there would be no need, to
wait for a perfect idea to implement a really cool smart server. We could do a
simple smart server with some sftp-like file system interface and some other
accelerator instructions. This would claim an other thing to the above:

2. Eztend your abstract filesystem API with optional higher level commands.

For example, the cacherev command now works like this (simplified):
        create_pristine_dir(dir)
        fs->build_revision(dir, archive, revision)
        fs->put_cached(dir, archive, revision)

You could create an optional method for the fs interface,
cacherev(archive, revision) and modify the above command like this:
        if (fs->cacherev) {
            fs->cacherev(archive, revision)
        } else {
            create_pristine_dir(dir)
            fs->build_revision(dir, archive, revision)
            fs->put_cached(dir, archive, revision)
        }

Your transports do not need to implement these optional methods and everything
works as it worked before. But a smart server transport could implement it as
a single prootocol command.

I am very new to ARCH, so I do not really know how it works. But this way
somebody could create an sftp-like backend with some accelerator commands that
makes run tla faster.
I know that it's not the perfect solution, you are very good guys and you
could create much smarter server. But this could be a fast solution and also a
research platform for moving higher level API commands to the server side.

What's your opinion?

Bye

$zilu

--
Szilard Hajba                   Symbion Ltd.
Phone:  (+36)20/203-31-56       H-9028 Gyor, Uj u. 38.
ICQ:    12892911                E-Mail: address@hidden
Skype:  hszilu