Re: smart upload server
On 12143 March 1977, Petr Jašek wrote:
>> > I've done some work on server and i'm asking you for comments/hints/etc.
>> > again..
>> Good. So you should have a protocol documentation written down, after
>> which you go and code stuff up. Could we see that please.
>> (IE, something vaguely like an RFC (but using a free license) (for
>> example IMAP or one of the SMTP ones), that lists exactly what can be
>> done, what is to be expected from both sides at that points, what
>> happens next, ...). The old old mail from Michael might be a good start of
>> one.
> I prefer to start code early and see what it takes, so right now i don't
> think it's necessary to do such thing, because I don't extend HTTP PUT in any way,
> but i will start with it and iterate on.
That way of acting is good to quickly see if an idea is good enough to
be followed at all, but then this way is also very good to get us to a
place where dak code currently is. Hard to maintain as it got sticked
together a lot over time by just doing something here or there, from
many people. The codebase got better over the recent past, but there are
still things we carry from ages ago which are hard to change, as we miss
a good testsuite *and* good "protocols/standards" for some. It regularly
happens that changing a bit on one place a totally different breaks down.
We want to avoid this with the sus.
Also, we want people able to easily code their own client interacting
with the SUS. WHile we plan to provide a client, we want them to be able
to just write up their own, and they shouldnt poke around in blackmagic
but be sure what happens when they do certain things.
That needs documentation like this.
> Now i'm trying to get into dak codebase,
Good. Should you happen to run by something that you see can be fixed,
dont hesitate to get us patches. :)
> to see what can be done with it which will bring me to some set of
> test I can do so far and according to it I will prepare this document
> with commands and return codes and so.
Check daklib/. There are checks in various places which we want you to
run in sus. (By importing and using the stuff daklib offers, of course).
A start is binary, with valid_deb, scan_package, check_utf8_package, the
formats stuff, lintian checks, maybe checking if a DM is allowed to
upload that package. The exact list of checks we need to fiddle out,
but a little later. Start with valid_deb and lintian, thats a good one.
Also, things like the changes class you can use too.
It might be some parts in daklib need changes to work with a SUS *and*
without it. Like, scan_package shouldnt do the insert_content_paths for
example. We should adapt the daklib source in such cases then that it
can work for SUS and "usual" dak. We shouldnt duplicate source.
> Can you give me some advices what to focus on and what I can or should use
> from dak and daklib. I've seen logs and confs but maybe i missed something.
You should use as much as possible of the existing codebase. :)
>> Also. Where do you have your version control system, so we can checkout
>> and see what you are up to?
> Look at http://github.com/pjx/dsus, it's my first time so please write
> anything usefull you have, I'm not sure about the licencing etc. etc.
For licensing, look at the files in dak. Take this header, use your
name. Then its GPL v2 or later, which is the same as dak uses. Thats the
best here.
> Thanks again and let me know if I'm on some good way or totally out...
Well, the config should be read from a file, but thats a minor detail.
Please keep your code documented. The more (good) docstrings, the
better, including those of variables. See much of the dak source, we
have a good part with it. :)
Try not using variable names like "f" please, but mostly you do use ones
that are longer.
Also, use classes and put em in different files, not one big one for all
of it.
For today, thats it. Not having done a deep look into code yet,
sorry. Maybe Torsten beats me to that, otherwise i do it the next
day(s).
--
bye, Joerg
What is a wedding? Webster’s Dictionary defines a wedding as ‘The
process of removing weeds from one’s garden.’
Reply to: