[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ggi-develop
Subject:    Re: [ggi-develop] Stem creation wrapper
From:       Andreas Beck <becka-list-ggidevel () bedatec ! de>
Date:       2006-09-17 13:46:35
Message-ID: 20060917134635.GB5320 () acs ! uni-duesseldorf ! de
[Download RAW message or body]

Peter Ekberg <peda@lysator.liu.se> wrote:
> On Sat, Sep 16, 2006 at 01:53:30PM +0200, Eric Faurot wrote:
> > On 9/16/06, Peter Ekberg <peda@lysator.liu.se> wrote:
> > change the ggNewStem prototype from
> > struct gg_stem * ggNewStem(void);
> > to
> > struct gg_stem * ggNewStem(struct gg_api*, ...);
> > with your original implementation.
> That's perfectly acceptable to me. Best so far. Good insight!

I agree. Putting a NULL there shouldn't kill someone who will 
anyway attach the APIs to his liking.

Moreover, a Stem on its own isn't very useful, right?

So most normal apps will attach at least one API - why not let them do
that right when craeting the stem.

And those apps that want to decide on whether to attach an API e.g. on
user preferences can still first attach the standard APIs they want and
later add individual ones.

> I think we should keep them, then an app can attach an optional api
> in an if statement after creating the stem with the required apis.

Right. It can fail more gracefully and it is easier to allow for APIs
the user selects from runtime config items.


CU, ANdy

-- 
= Andreas Beck | Email: <becka-sig-ggi@bedatec.de>  =

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
ggi-develop mailing list
ggi-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ggi-develop
[prev in list] [next in list] [prev in thread] [next in thread]