You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apreq-dev@httpd.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2002/02/18 20:18:16 UTC
naming conventions & data structures (was Re: proposed 2.0 features/layout)
Stas Bekman <st...@stason.org> writes:
> > The current header files are inconsistent and have
> > too much cruft. Although I prefer using a common
> > naming convention for both macros and functions within
> > header files, I could live with adopting a different
> > scheme for macros. But the current .h files are not
> > consistent in this regard, and IMO that needs to change.
>
>
> + for common naming convention.
OK- some clarification on this: macros that have function-call
semantics (i.e. the args appear only once in the definition)
should be lower-case; macros that may not be safe, like say
#define apreq_MAX(a,b) ( (a) < (b) ? (b) : (a) )
MUST have (some) upper-case letters.
Another issue I think we should address is what sort of
data structures we'll use to hold the param's, cookie's,
and upload's. In (the still-pending-Jim's release of) 1.0,
we use apache arrays and tables, and a simple home-grown
linked list for uploads.
For 2.0, I'm leaning *against* using ap_hash because it doesn't
seem to support multivalued keys as well as apache 1.x tables
do (tables are implemented as a special kind of apache array;
the hash-like iterface for an apache table is just a ruse.)
IOW, if we decide on using a real hash, it probably should be
list-valued, and I think that means we'll need to roll-our-own
version of ap_hash. IMO it will be simpler to just use a linked
list (a'la ap_ring.h) as the underlying structure for everything,
and just superimpose a hash-like interface on top of it.
Thoughts?
--
Joe Schaefer
Re: naming conventions & data structures (was Re: proposed 2.0 features/layout)
Posted by Issac Goldstand <ma...@beamartyr.net>.
Not sure if this is already part of the API, but with the new proposed
method of registering POST handlers, is there some function that will
tell Apache handlers what kind of content was sent to it? I can't say
that it would always be necessary - or even ever, perhaps - but it would
leave a door open that could possibly become important... Once people
can develop their own handlers for parsing the POSTs, you can never tell
what sort of cool applications they may develop, but it's possible that
the POST method might be a variable in some complex application...
Just my two cents...
Issac
Joe Schaefer wrote:
>Stas Bekman <st...@stason.org> writes:
>
>>>The current header files are inconsistent and have
>>>too much cruft. Although I prefer using a common
>>>naming convention for both macros and functions within
>>>header files, I could live with adopting a different
>>>scheme for macros. But the current .h files are not
>>>consistent in this regard, and IMO that needs to change.
>>>
>>
>>+ for common naming convention.
>>
>
>OK- some clarification on this: macros that have function-call
>semantics (i.e. the args appear only once in the definition)
>should be lower-case; macros that may not be safe, like say
>
> #define apreq_MAX(a,b) ( (a) < (b) ? (b) : (a) )
>
>MUST have (some) upper-case letters.
>
>Another issue I think we should address is what sort of
>data structures we'll use to hold the param's, cookie's,
>and upload's. In (the still-pending-Jim's release of) 1.0,
>we use apache arrays and tables, and a simple home-grown
>linked list for uploads.
>
>For 2.0, I'm leaning *against* using ap_hash because it doesn't
>seem to support multivalued keys as well as apache 1.x tables
>do (tables are implemented as a special kind of apache array;
>the hash-like iterface for an apache table is just a ruse.)
>
>IOW, if we decide on using a real hash, it probably should be
>list-valued, and I think that means we'll need to roll-our-own
>version of ap_hash. IMO it will be simpler to just use a linked
>list (a'la ap_ring.h) as the underlying structure for everything,
>and just superimpose a hash-like interface on top of it.
>
>Thoughts?
>
Re: naming conventions & data structures (was Re: proposed 2.0 features/layout)
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
> Joe Schaefer wrote:
>
> > OK- some clarification on this: macros that have function-call
> > semantics (i.e. the args appear only once in the definition)
> > should be lower-case; macros that may not be safe, like say
> >
> > #define apreq_MAX(a,b) ( (a) < (b) ? (b) : (a) )
> >
> > MUST have (some) upper-case letters.
>
> why not having all macros UP-cased?
>
You're right- I don't know why I even raised this issue.
Probably insufficient sleep/caffeine, or some combination
of the two.
--
Joe Schaefer
Re: naming conventions & data structures (was Re: proposed 2.0 features/layout)
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Stas Bekman <st...@stason.org> writes:
>
>
>>>The current header files are inconsistent and have
>>>too much cruft. Although I prefer using a common
>>>naming convention for both macros and functions within
>>>header files, I could live with adopting a different
>>>scheme for macros. But the current .h files are not
>>>consistent in this regard, and IMO that needs to change.
>>>
>>
>>+ for common naming convention.
>>
>
> OK- some clarification on this: macros that have function-call
> semantics (i.e. the args appear only once in the definition)
> should be lower-case; macros that may not be safe, like say
>
> #define apreq_MAX(a,b) ( (a) < (b) ? (b) : (a) )
>
> MUST have (some) upper-case letters.
why not having all macros UP-cased?
> Another issue I think we should address is what sort of
> data structures we'll use to hold the param's, cookie's,
> and upload's. In (the still-pending-Jim's release of) 1.0,
> we use apache arrays and tables, and a simple home-grown
> linked list for uploads.
>
> For 2.0, I'm leaning *against* using ap_hash because it doesn't
> seem to support multivalued keys as well as apache 1.x tables
> do (tables are implemented as a special kind of apache array;
> the hash-like iterface for an apache table is just a ruse.)
>
> IOW, if we decide on using a real hash, it probably should be
> list-valued, and I think that means we'll need to roll-our-own
> version of ap_hash. IMO it will be simpler to just use a linked
> list (a'la ap_ring.h) as the underlying structure for everything,
> and just superimpose a hash-like interface on top of it.
>
> Thoughts?
If we only could throw a linked list into apr_hash entry, but it works
only with strings :(
May be we need to raise this issue at apr-dev? I'd prefer to have an
apr-based solution rather than rolling our own. I can see other projects
needing this functionality.
IMO, the fastest (coding wise) solution would be to copy apr_hash and
let it accept a struct instead of a string as a value. Than we can
always link from the head struct further to get multi-valued hash.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/