Re: [AD] fshook changes

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On January 10, 2009, Peter Wang wrote:
> On 2009-01-10, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > Over the past few months I've gotten some feedback which is good, not as
> > much as I was hoping for, which is bad :(
> >
> > But anyhow I have a growing TODO list for the file system code that I'd
> > like to share, and see if theres anything I'm forgetting.
> >
> > In no particular order:
> > - fix up rest of documentation, and resolve XXX comments
> > - change some functions to return bool, and fill in errno as necessary
> > - implement missing functions: al_find*, abs/rel/cannon conversions
> > - rename al_fs_[im](get|put)wl to al_readbitnum[lb]
> >   - al_fs_igetw -> al_read16l
> > - AL_ -> ALLEGRO_
> > - al_fs_readdir: have it fill in a ALLEGRO_ENTRY struct
> > - convert remaining parts of allegro to fshooks
> >   - config.c, icodec, acodec (some is done already)
> > - bulk rename of api to a more a5 consistent scheme:
> >   - al_fs_create_handle -> al_create_entry
> >   - al_fs_entry_name -> al_get_entry_name
> >   - al_fs_exists -> al_exists
> > - add a al_set_appname function (to be used in al_get_path, and possibly
> > other places)
> >
> > The bulk rename is currently at the bottom of my list, I figure it can
> > wait till the rest is done.
> >
> > So if anyone has any comments or suggestions, PLEASE pass them along.
>
> - Implement a memory block reader/writer and one other reader/writer
>   (e.g. gzip, zip, whatever).  Do it in addon space so we know that
>   it can be done without access to Allegro internals.

Huh, that was in my original list, oops. Yes I plan on having a memfile api, 
and a physfs hook driver.

> - (This is more path related).  Figure out what to do with character
>   encoding of paths and fix it accordingly.

What I _really_ want to do here is have allegro convert whatever it gets from 
the OS into the "current" allegro format. Yes, it might break path names, but 
then just set the allegro format to what you need (UTF8 aught to cover 
everything for the foreseeable future).

Or possibly somehow detect the OS format, and always set the allegro format to 
it? (at least within reason, ASCII, UTF8 and UCS16 or whatever)

I _really_ don't want to have to force the user to convert every little string 
they get from allegro into allegro's own default format. It seems rather 
redundant.

Now, imo, a more "proper" solution would be to provide our own ALLEGRO_STRING 
type, and store the encoding and a nice vtable with it. But I'll bet most 
people aren't too interested in that.

> Peter
>
>
> ---------------------------------------------------------------------------
>--- Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/