[Mental@NeverLight.com: Re: [Pas-dev] Precompiling psp's]

[Mental <Me...@Ne...>]

On Fri, Mar 01, 2002 at 03:01:19PM -0500, Kyle R . Burton wrote:
> Thats right.  I think we're kind of saying the smae thing.  Just from
> different approaches.  If we create the build tool as an object so either
> the request handler, _or_ some command line tool can invoke it to 
> both decide if a file should be recompiled, and recompile it, then great.
> 
> I just don't want duplicated code/behavior -- since both the build tool
> and the request handler have to perform the 'is out fo date' check based
> on dep information, the compiler feels like the right place to put it for
> now.  Though a build tool as an object would be better.
> 

I was thinking of having the build tool invoke the RequestHandler. But now
that I think aobut it we could do what you're talking about in the
compiler. But I still think the compiler should just compile. 

Maybe the request handler should talk to an object broker that knows how
to talk to the compiler (if it thinks it needs to). This way both the
build tool and the request handler share the same code (the object
broker) and the compiler stays a compiler. My fear is that we'll wind up
over engineering the compiler and wind up with emacs. :)

I just want something that compiles stuff. I have no problems at all with
asking Org::Bgw::Pas::ObjectBroker for an object. In fact, I could care
less what it does to get me the object, so long as it tells me where it
is.

Besides, then we'll be all buzz word compliant :)

At least I think so. Seems to fit the definition:

In brokering a client request, an ORB may provide all of these services:

    * Life cycle services, which define how to create, copy, move, and
    * delete a component
    * Persistence service, which provide the ability to store data on
    * object database, , and plain files
    * Naming service, which allows a component to find another component
    * by name and also supports existing naming systems or directories,
    * including DCE, , and Sun's NIS (Network Information System).
    * Event service, which lets components specify events that they want
    * to be notified of
    * Concurrency control service, which allows an ORB to manage locks to
    * data that transactions or threads may compete for
    * transaction service, which ensures that when a transaction is
    * completed, changes are committed, or that, if not, database changes
    * are restored to their pre-transaction state
    * Relationship service, which creates dynamic associations between
    * components that haven't "met" before and for keeping track of these
    * associations
    * Externalization service, which provides a way to get data to and
    * from a component in a "stream"
    * Query service, which allows a component to query a database. This
    * service is based on the SQL3 specification and the Object Database
    * Management Group's (ODMG) Object Query Language (OQL).
    * Licensing service, which allows the use of a component to be
    * measured for purposes of compensation for use. Charging can be done
    * by session, by node, by instance creation, and by site.
    * Properties service, which lets a component contain a
    * self-description that other components can use.


Maybe my definition is a bit off, but you get teh idae. 

I hope.

--
Mental (Me...@Ne...)

I watched the Indy 500, and I was thinking that if they left
earlier they wouldn't have to go so fast.
--Steven Wright

GPG public key: http://www.neverlight.com/Mental.asc