friday, 9 march 2007

posted at 18:42
tags:
From: Robert Norris
To: TeamAROS
Subject: Changing the DOS Packets bounty

Hi Team,

I've reached a block on the DOS Packets bounty that I can't work my way
around, so I need this group to help me figure out what to do. Here I
outline the issue and suggest a resolution.

I've taken the existing bounty description to mean full support for DOS
packets on both the device/filesystem side (ie allowing us to compile
and use existing packet-based filesystems from AOS/MOS) and the API side
(ie DOS calls like DoPkt()).

The former is largely complete via packet.handler, as demonstrated by
the availability of fat.handler. The latter I believe to be impossible
to complete without either the removal or a significant redesign of the
AROS-specific IOFS system.

If I'm reading the bounty correctly, then I can't complete it. If the
powers that be (ie the designers and/or advocates) decide that IOFS
should be kept, then the packet API can't be made to work. If they do
decide that it should be redesigned or removed, then its huge amount of
work that I can't complete before the bounty deadline.

On the other hand, if the bounty doesn't include the API, then I'm done,
but I don't feel like thats really fair to the people who thrown money
at this. The expectation was that with DOS packets available, Marek's
filesystems would be ported shortly after. Since that won't happen, I'd
feel weird about taking the cash if people haven't at least got
something close to what they paid for.

So, I propose modifying the bounty so that its clear that it doesn't
include API, but includes a completed fat.handler that supports writes.
This way people who put up cash at least get something tangible at the
end of all this.

Of course something still needs to be done about IOFS, and I'll be
pursuing it further myself, but I think it needs to be outside the scope
of this bounty.

So to summarise, I'd like the bounty to read as follows:

 - ability to compile and use existing packet-based filesystems
 - a working port of FATFileSystem, extended to support writes
 - a porting guide to assist developers porting filesystems

Deadline would remain the same: 31 April 2007.

What do you all think?

Thanks,
Rob.