Re: [AD] SF.net SVN: alleg:[12071] allegro/branches/4.9

[Peter Wang <novalazy@xxxxxxxxxx>]

2009/4/16 Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>:
> On Wed April 15 2009, Peter Wang wrote:
>>
>> Another reason: most of the time I didn't have a good idea what you were
>> trying to do.  You posted function prototypes and a few rough
>> descriptions, the rest of it being inside your head.  Since I didn't
>> understand, I didn't speak up.  I did ask for documentation a few times.
>
> I was asking for input, suggestions and questions. if you had questions you
> should have asked.

Better late than never.  Let's leave it at that.

>> > > > No one will be used to allegro's api, so they shouldn't find a
>> > > > different, more sane ordering /bad/.
>> > >
>> > > The order is completely arbitrary (there is no reason one order should
>> > > be better than another, but it does somewhat depend on what you're
>> > > used to), so I would say the best thing to do is go with whatever the
>> > > "standard" convention is. Otherwise it gets confusing.
>> >
>> > Well then, why don't we do that for everything then? Lets change the api
>> > back to being a much closer clone of stdio as I had originally planned
>> > then.
>>
>> That's more than fine with me.  I would prefer it.
>
> I made a few moves away from stdio on your recommendation fwir.

We might be referring to different things.  I definitely would have suggested
to deviate from stdio and put all ALLEGRO_FS_ENTRY arguments *first*.

When I say, that's "fine with me", I was thinking that I wouldn't mind if
we only had roughly stdio level of functionality: reading/writing streams.
That would be enough to use our image/sound loaders with external .zip
libraries and so on, which is the main thing.  I do think the directory
listing stuff is useful, and the stat/timestamp stuff goes with that.

But, for example, do we need the mktemp() equivalent?  If you need a
temporary file, I can't imagine you want to create one inside a .zip file or
over the network.

Peter