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

[Odysseas T. <ody...@ya...>]

Justin,

Thats a good suggestion and we will look into 
creating a standard communication "bus", where
modules can talk to or listen in.

Keep in mind though that such a facility is 
more applicable when you have indendently created
modules as opposed to use it for the communication
between the "pieces" of your application.

To give an example: 
my.yahoo could use a similar "bus" architecture to
let the various modules in my.yahoo page be aware
of stock tickers that you are adding in your
portfolio.
For example the stock news module will prioritize high
news about companies whose ticker you are monitoring
in the
stock portfolio module.

However thats not how Yahoo did it.
It decided to see the two modules (portfolio, stock
news etc) as just viewports of one integrated
application. All these viewports are agreeing on
common structures that are either in the DB or in  
Session vars. 

There is no reason to argue which approach is good or
bad. Simply understand that there contexts where one
may be more applicable than the other.

odysseas

--- Justin F
arnsworth <je...@ey...> wrote:
> Alex:
> 
> We are still futzing along with development of
> modules that
> will ultimately be used in our production sites,
> with the
> r2 constraints.  Our enthusiasm for the BC model and
> the
> implications for the future, remains unabated.
> 
> Now, one of the things that we feel a "need" for is
> a way
> to pass data downstream from one module to another. 
> It
> may be that we are using BC in a way that is
> unanticipated,
> but our way, right now, is what we think best.
> 
> Here is an example to illustrate.  Let us say that
> we are
> trying to give the location of the nearest ACME CORP
> store
> to the site user, based upon the entry of the site
> user's
> ZIP code.  Our module load order may be, after the
> round
> trip passing in the ZIP:
> 
> 1.  Module with some decoration output
> 2.  Module to merely compute great circle distance,
> 	no output
> 3.  Module to get the nearest store out of the
> 	database, no output
> 4.  Module with some decoration and output of result
> 
> 
> For this example data has to be dropped into global
> scope, Hansel and Gretel style, by module 2 for
> module 3.
> Then data has to be put into global scope by module
> 3
> for module 4.
> 
> THIS IS NO PROBLEM with the facility of BC.  But, in
> a production environment, when our business is going
> to
> create numerous modules that maybe do tasks that
> only
> differ slightly, and depend upon data "passed in"
> from
> a previous manipulation of an upstream module, we
> have
> to agree among ourself as to the place where this
> data
> will be picked up, and results dropped.  So, we may
> do something like, everything will be stuck in
> the EYE_LUNCHBOX array/data structure, and comments
> will be put in
> the module source as to where it expects things,
> and where it will drop things in the EYE_LUNCHBOX
> datastructure/array.
> 
> This is still no problem.  However, one of the
> advantages
> of BC will be the contribution or interchange with
> other
> developers of BC modules.  Probably every shop will
> have
> its "own conventions", and foreign modules may have
> to
> be tweaked slightly.
> 
> As I said, this is no problem, but I think it would
> be a good idea to consider that BC supplies upon
> initialization a standard place for data passing.
> Sure, we could do it, and put "EYE_LUNCHBOX[]" into
> our copy of Init.  But, I would rather you supply
> the
> facility, and that this would be available for all
> BC users.  You are not going to dictate that data
> to be passed has to go there.  But, by you setting
> up this facility, at least everybody could start
> using it.
> 
> I don't think this is a trivial request, because if
> BC grows up to be big, and people "use" data
> dropping
> and picking up from a built-in standard place, the
> ultimate interchange of code between developers
> would
> become easier.
> 
> Regards,
> -- 
> Justin Farnsworth
> Eye Integrated Communications
> 321 South Evans - Suite 203
> Greenville, NC 27858 | Tel: (252) 353-0722
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
>
http://lists.sourceforge.net/lists/listinfo/binarycloud-dev


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/