Re: [binarycloud-dev] A Request for "A Standard"

[Alex B. <en...@tu...>]

> Now this is NOT the start of a polemic.  And, remember, the
> end result of this request is one line in Init establishing
> an array called, for example, BC_LUNCHBOX, in global scope.
> This would not, I allege, cause you to be injustly accused
> of forcing policy.

it would likely be a class, but I did a little more thinking with odysseas
about this one:

    -a) given that you control load order, you can just have the modules
talk to themselves.
    -b) yes, we could make a simple class, and yes, we may well end up doing
that. but at the moment I don't see the reason.

say you did exactly what you described in your earlier mail. all you would
need to do is get the property from page.

> And now, dah, dah, for the "complex example" that intersects
> with, shall we say, maintainability and administration of
> 500 web sites that need/use the great circle distance
> between two ZIP's.

cool!

> 1.  This site for bird lovers-in-detail has a computation
> ability to determine how long certain types of
> birds take to fly between cities.  The distance
> is computed, then a table is looked into for
> average MPH for a particular type of bird.

Holy crap that's esoteric! I love it!

> 2.  This site for bird lovers-in-extreme-detail has
> the same thing, but, but, they want the site
> to go to the US weather bureau and get the current
> prevailing wind, compensate for the flight direction,
> and give the time for flight.

Whee!

> 3.  This site for bird lovers-in-really-extreme-detail has
>       the same thing, but, but, they want the site
>       to go to the US weather bureau and get the current
>       prevailing wind, compensate for the flight direction,
> and THEN take into consideration the day of the year
> because the cuckolded titmouse is known to fly faster
> in the summer than the winter -- and give the time for flight.

Ok.

> 4.  This site for glider pilots wants the same-kind-of thing
> but wants a look-up table for glider types.
> 
> n-1.
> n.
> 500.
> 
> Yes, I know, I could do some libraries, and maybe I am thinking
> wrongly.  But, by simply loading in sequence a set of maybe
> 3-5 modules I could solve a _lot_ of problems by refining the
> granularity if I have data passing.

Wait, why?

Why would you not have a library class that you can send some params lik
wind speed, bird type, bird mph, etc and get a result back?

How about a simpler example:

    I have a map module. It displays a map of some address, say a defailt
address initially.
    On the same page, I have a "customer display" module. That contains some
address info.


Say I wanted to have the map module display the customer location based on
the customer being displayed in the other modules.

Why not have the customer modules make that variable available in itself?
Then we load the customer module first, and the map module looks at the
customer modules and displays that address.

What I'm trying to say is you don't need that global array, but you can have
the modules directly talk to one another. Eliminate the bureaucracy, as it
were.

> I sure as hell am not going to design 500 different modules.
> I will pay the price of the exposure of having to design 500
> different layouts.  I also, by module loading order, have the
> ability of dynamic "switching" by, say, loading different
> look-up tables, or even different methods of, say, Great
> Circle computations, something that may be necessary in
> Northern Canada where longitude convergence makes certain
> algorithms less accurate than others.

Right, but again I think that application belongs in a lib.

> Fantasy, you say?  Sure.  But I seem to believe that the
> correct "way" to use BC is to atomize down more than you.


I think so.
But the point about BC is you _can_ build your original structure. That's
not how I would do it but that's not the point.

You could build all those modules, and have them talk to each other by
getting variables from each module class. That would work fine.

> do.  BC is a Lego set for me, and I like to build to finer
> detail, therefore, my perception of BC is that it allows
> to build with small pieces, not large pieces that are
> "application size".

You can build both!

> NOW, I STILL DON'T know what these mystical "Managers" are
> going to look like.  Are they going to allow me to do
> generic queries for ZIP on potentially 500 databases of
> different names and ZIP imbedded in potentially 10
> different field names in potentially 10 different table
> names, AND STILL USE SOMETHING LIKE one generic, but
> configurable, module that solves all requirements from
> 500 customers?  I donno.  I certainly can imagine that

Yes.

> for some reason or other, I would wish to simply insert
> one extremely "thin" module in between module 3 and
> module 4 merely to use Init() (Output just returns)
> to go look something
> up in a database and deposit the data behind it
> for use, or for overriding data that the previous
> module computed, that succeeding modules _may_
> expect.

Right! and you can do that.

> And, I have not even addressed the great promise of BC that
> is important for me, namely the hope that I will be
> able to snarf BC modules from other developers, while
> contributing modules for public consumption, WHILE
> NOT having to, say, install 100 libraries that are
> necessary for these feriners-gewritten-Kode.  I think
> that a data-passing facility would allow greater
> compatability for exchange.

I completely agree!
But I don't see the need for a controlling class for this stuff. I think you
can just have the modules talk directly to each other. no reason to put in
an intermediary.

> I donno.  I have started thinking this way, I will
> keep thinking about it.  Maybe I don't need data
> passing to trailing modules...  It seems like it
> would be useful, right now.

You absolutely do need it. But, you can do it now :)

_a



--
alex black, ceo
en...@tu...

the turing studio, inc.
http://www.turingstudio.com

vox+510.666.0074
fax+510.666.0093