binarycloud-dev — development list for binarycloud

Re: [binarycloud-dev] make configuration

[jason <ja...@gr...>]

I'll propose a potential concern here. i'm not sure how HTTPS/SSL is
handled (site level vs. page level), but if the secure hostname/path
differs from the non-secure hostname/path, make may need to know this at
build time.

For example:
if only the checkout portion of a site is SSL enabled, and it's moved to
a seperate docroot to keep visitors from viewing the rest of the site
encrypted, one may want just the checkout.php to sit elsewhere


http://mysite.com -> /var/www/html/mysite.com/
   which has shop.php (categories.php, specials.php, etc etc)
https://mysite.com -> /var/www/html/secure/mysite.com/
   which only has checkout.php


This may be a bit too oddball for BC to support.  _shrug_

jason



alex black wrote:
> I'm building a spec for 'make configuration' and wanted some opinions:
> Any other suggestions?

Re: [binarycloud-dev] binarycloud/base/mod

[jason <ja...@gr...>]

makes sense to me... seems like the best place to put "factory" modules.

jason

alex black wrote:
> what does everyone think about having binarycloud/base/mod/ in the source
> tree?
> I'm thinking that we're going to have a set of modules that will be required
> by certain builders and managers ( the JSRequest and CSSRequest Managers
> come to mind)
> 
> thoughts?

[binarycloud-dev] make configuration

[alex b. <en...@tu...>]

hi all,

I'm building a spec for 'make configuration' and wanted some opinions:

List of Make parameters:

user/site_name/conf/MakeConf.xml
    -Auto-make if make all is called?
    -Site long name
    -Use Zend Encoder?
    -Clean Comments, etc?
    -Standalone or shared binarycloud core?

I could also add:
    -Standalone or shared htdocs?
    -Use Default file set (i.e. if a file doesn't exist in the site tree
that is needed by the system, use the copy of the file from user/default/
---
Any other suggestions?

I suppose we could go haywire and ask for the location to htdocs from build
root, which would allow you to have different "htdocs sets" for different
servers with multiple binarycloud sites..

does anyone think that would be useful?
also, please: any other ideas you can all think of re: make configuration?

Separately, we may want to have Locations (i.e. "if I'm on this hostname,
set docroot and bc root in such a way) - in r1, it was done just by editing
the prepend and adding whatever code you wanted... I'd like to formalize it
through Init in some way. I suppose we could move the code that sets docroot
and bc_path out to a "Locations.php" file in user/site_name/conf/ - but I'm
not sure I like it there or that I like the idea of having the code
separate.

In a perfect world, my preference would be to have a ./configure system that
would be installed both in the source and build tree, with different
purposes:
    -./configure in the source tree would populate the tree with a set of
Makefiles, and configure paths to PHP command line, etc.
    -./configure in the build tree would configure the 'built' installation
to set paths based on rules defined in a php file.

That system would solve any path problems 100%, without incurring overhead
to look at hostname or something on every page render.

opinions welcome...

_a

[binarycloud-dev] binarycloud/base/mod

[alex b. <en...@tu...>]

hi all,

what does everyone think about having binarycloud/base/mod/ in the source
tree?
I'm thinking that we're going to have a set of modules that will be required
by certain builders and managers ( the JSRequest and CSSRequest Managers
come to mind)

thoughts?

_a

Re: [binarycloud-dev] xml2php

[alex b. <en...@tu...>]

> The previous version of xml2php does not correctly handle xml-based arrays
> which
> need to be key-less (for example, "load" array in bcp.xml). xml2php CAN'T
> know when you need a keyless array (unfortunately it has no artifical
> intelligence built-in...), so we must tell it. In the LATEST xml2php
version
> it uses <things><thing></thing></things> syntax. The idea was that a
> standart array defined in xml as
>     <load>
>         <module>
>             <id>product_list</id>
>         </module>
>     </load>
> would be rendered as (note that we DO NOT want the "module" array to have
> it's name (key) here!
>     'load' => array(
>         'module' => array(
>          'name' => "product_list",
>         )
>        ),
> but some xml-thing like this
>     <modules>
>         <module>
>             <id>product_list</id>
>         </module>
>     </modules>
> will be rendered as following (note that this time the array has no key,
> which is what we all want).
>    'modules' => array(
>         array(
>          'id' => "product_list",
>         ),
>        ),
> The only place in which we need to change something is bcp.xml definition,
> where we should rename "load" array to "modules" array AND change the page
> to use "modules" instead of "load" as well. The latest (included) XMLUtils
> version handles that properly. A changed Page.php is included as well.
Good
> luck with testing.

Great. I'll integrate this and check it in on monday.

> xml file's type definded in makefile (we can read it from the file name!

yep! :)

_a

[binarycloud-dev] xml2php

[Andris S. <an...@do...>]

Hello all,

The previous version of xml2php does not correctly handle xml-based arrays
which
need to be key-less (for example, "load" array in bcp.xml). xml2php CAN'T
know when you need a keyless array (unfortunately it has no artifical
intelligence built-in...), so we must tell it. In the LATEST xml2php version
it uses <things><thing></thing></things> syntax. The idea was that a
standart array defined in xml as
    <load>
        <module>
            <id>product_list</id>
        </module>
    </load>
would be rendered as (note that we DO NOT want the "module" array to have
it's name (key) here!
    'load' => array(
        'module' => array(
         'name' => "product_list",
        )
       ),
but some xml-thing like this
    <modules>
        <module>
            <id>product_list</id>
        </module>
    </modules>
will be rendered as following (note that this time the array has no key,
which is what we all want).
   'modules' => array(
        array(
         'id' => "product_list",
        ),
       ),
The only place in which we need to change something is bcp.xml definition,
where we should rename "load" array to "modules" array AND change the page
to use "modules" instead of "load" as well. The latest (included) XMLUtils
version handles that properly. A changed Page.php is included as well. Good
luck with testing.

Andris Spruds

P.S.
I had no free time to deal with xml.php => php.xml problem, but this should
be fairly easy to fix. Even more, since we will be using
file_name.file_type.xml naming scheme (for example index..bcp.xml for page
definition or god.rle.xml for a role definition), there is no need to have
xml file's type definded in makefile (we can read it from the file name!
mmm...)

[binarycloud-dev] TODO

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

hi all,

I've revised the TODO so it's an index to the tasks/ directory (in cvs
shortly)... basically there will be a 'task file' for each of the tasks
listed in the todo, which gives the reader a pretty clear picture of what
needs to happen.

here's the new TODO: (can anyone see anything that's missing from this?)

best,

-a

##
# r2/TODO
##

Core
------------------------------------------------
-PEAR_Error integrated and in wide use
-All core classes use Request for user-space variables
-Build Authentication and Permissions

EntityManager & Friends
------------------------------------------------
-Test QueryManager
-Re-build EntityManager to handle new Entity Definitions
    Including Validators and Processors
-Build Tests for the new EntityManager
-Build TemplateManager
-Build EventManager
-Build JSRequestManager
-Build CSSRequestManager
-BUild Basic set of Validators and Processors

Make
------------------------------------------------
-Multi-site make 
(http://www.geocrawler.com/lists/3/SourceForge/9659/0/6177512/)
-Gif, CSS, Browser-rsrc Standards
-PHPDoc Integrated
-Configuration scheme for Make
-String Keyer & Repositories
-Static Module Embed Syntax
-Last Modification Date Check to Speed Makes
-Recognize FileName.lang_code.php in place of FileName.php
-Extend XML2PHP to handle Entity Definitions
-Build ENT2SCHEMA utility which will build metabase XML schemas from Entity
Definitions
-Extend ENT2SCHEMA to output SQL
-Integrate Zend Encoder
-Integrate Misc Tools (comment stripper, etc)

Builders
------------------------------------------------
-Get UIControlBuilder Working
-Build FormBuilder (from existing code)
-Build ListBuilder (from existing code)
-Build WizardBuilder (from existing code)
-PageDefBuilder
-TreeBuilder (post-r2a release)
-CalendarBuilder (post-r2a release)
-EmailBuilder (post-r2a release)
-FaxBuilder (post-r2a release)
-PDFBuilder    (post-r2a release)


Misc
------------------------------------------------
-Complete, fully functional HTML entity encoding lib
-Encapsulation scheme for native php templates
-All files have the current LGPL header.
-Build golden "reference module"

RE: [binarycloud-dev] is_default, default, set_default, etc.

[Andreas A. (Thyrell) <a.a...@th...>]

Hi Alex,

>> I have no problems with is_ or another descriptive naming. Important is
to
>> unify it in all def arrays.

> In this case I prefer "default" :)

So I do :)

Andi

Re: [binarycloud-dev] is_default, default, set_default, etc.

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

> Hi Alex,
> 
>> default is good.
>> but if we do that, is_ isn't allowed anywhere in the def arrays.
> 
> I have no problems with is_ or another descriptive naming. Important is to
> unify it in all def arrays.

In this case I prefer "default" :)

-a

[binarycloud-dev] is_default, default, set_default, etc.

[Andreas A. (Thyrell) <a.a...@th...>]

Hi Alex,

> default is good.
> but if we do that, is_ isn't allowed anywhere in the def arrays.

I have no problems with is_ or another descriptive naming. Important is to
unify it in all def arrays.

Andi


----- Original Message -----
> Hi Alex,
>
>
> >> Thats a problem in the Langs.xml.php. The XML Tag
> >> <is_default> is not right,
> >> <flag_default> is interpreted by the Lang class. It's just a
> >> mismatch between the xml def and the Lang class.
>
> > oh.
> > I'll commit that.
> > I have no problem with is_default.
>
> what about just default?
>
> Andi



_______________________________________________
binarycloud-dev mailing list
bin...@li...
https://lists.sourceforge.net/lists/listinfo/binarycloud-dev

Re: [binarycloud-dev] how close are we to a stable environment?

[alex b. <en...@tu...>]

> What do you guys suspect the ETA is to begin developing against a stable
> binarycloud2 system?

Depends on what you need to do: the page render pipeline works fine, but
EntityManager, etc aren't done.

The ETA of EntityManager and is associated infrastructure (along with the
other make-related stuff that needs to happen) depends entirely on how many
people are contributing code, and how much time I have based on what
projects my company is doing.

I'd guess 2 months, but that's a guess. Coule be a lot faster or slower than
that.

_a

> //.s

Re: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

[alex b. <en...@tu...>]

default is good.

but if we do that, is_ isn't allowed anywhere in the def arrays.

8)

_a

----- Original Message ----- 
From: "Andreas Aderhold (Thyrell)" <a.a...@th...>
To: <bin...@li...>
Sent: Saturday, September 08, 2001 3:24 AM
Subject: RE: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL


> Hi Alex,
> 
> 
> >> Thats a problem in the Langs.xml.php. The XML Tag
> >> <is_default> is not right,
> >> <flag_default> is interpreted by the Lang class. It's just a 
> >> mismatch between the xml def and the Lang class.
> 
> > oh.
> > I'll commit that.
> > I have no problem with is_default.
> 
> what about just default?
> 
> Andi

RE: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

[Andreas A. (Thyrell) <a.a...@th...>]

Hi Alex,

>> I modify the datasources.xml.php to fit my configuration
>> (odd to be named xml.php and not php.xml. It's a bit
>> confusing.). BTW, shouldn't

> That's a bug. Andi's fixing it this week, I think. The correct
> (and spec'd) naming scheme is the one you like (and I like, and > everyone
likes): .php.xml

yepp, I'll do next tuesdeay. Then I've enough time to do the changes.


Andi

RE: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

[Andreas A. (Thyrell) <a.a...@th...>]

Hi Alex,


>> Thats a problem in the Langs.xml.php. The XML Tag
>> <is_default> is not right,
>> <flag_default> is interpreted by the Lang class. It's just a 
>> mismatch between the xml def and the Lang class.

> oh.
> I'll commit that.
> I have no problem with is_default.

what about just default?

Andi

RE: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

[Andreas A. (Thyrell) <a.a...@th...>]

Hi Roni,

>> WinNT/2k
>> IIS 5
>> PHP4
>> MySQL 3.xx
>>
>> I mean not running make, but the the maked binarycloud 
>> on the webserver?
>>
>> Any drawbacks, problems or specialities (except using 
>> driveletters in 
>> paths)

> actually everytime when the new version comes out, I will 
> test on both Apache and IIS in Win32 platform, and besides 
> those problem which appera in all platform there is no 
> specific problem which just appear in IIS with all example 
> come with BC.

Cool. Thanks Roni..

Andi

[binarycloud-dev] how close are we to a stable environment?

[Seth B. <se...@su...>]

What do you guys suspect the ETA is to begin developing against a stable
binarycloud2 system?

//.s

Re: [binarycloud-dev] Yee haw

[Albert L. <a.l...@ve...>]

I saw that, its awesome. This make config whizz-bang you speak of sounds
rad.


----- Original Message -----
From: "Alex Black" <en...@tu...>
To: "binarycloud-dev" <bin...@li...>
Sent: Friday, September 07, 2001 2:28 PM
Subject: Re: [binarycloud-dev] BC Serious Concerns, Production Standpoint


> have a look at my response :)
>
> > Hey - I've got some things to say about this topic. What you've
described is
> > actually how I'm doing things now, and I was really interested in
switching
> > to bc to escape this. Moreso, all of my sites are exactly the same, only
> > thing that changes is the information and graphical configuration, which
is
> > DRASTICALLY different, i.e. - if one user logged in and ended up at the
> > wrong site, that would be _really_ bad.
> >
> > So in a way, physical location and separate db's are helpful for
ensuring no
> > data gets mixed up. However, as Justin has pointed out, its makes
updating
> > functions extremely tedious. There is honestly no need for me to have 50
> > copies of sessionauth running. Also, if I add a function to my service,
I
> > would like to plug it into the central engine and let it work itself out
> > from there.
> >
> > Is there any way that we can pare this thing down to one set of
functions,
> > then have different folders/modules for the various sites? The progress
> > everyone's been making is truly awesome, but this is a big hang up for
me I
> > gotta say.
> >
> > Alby
> >
> >
> > ----- Original Message -----
> > From: "Justin Farnsworth" <je...@ey...>
> > To: "BINARY_CLOUD" <bin...@li...>
> > Sent: Friday, September 07, 2001 12:51 PM
> > Subject: [binarycloud-dev] BC Serious Concerns, Production Standpoint
> >
> >
> >> Guys:
> >>
> >> I have been following silently the shifting sands of BC lately
> >> without comment, trying to keep up with the developing trends.
> >>
> >> This message may be long, and reflects my understanding of the
> >> current file layout and housekeeping related to the make system,
> >> and in particular, the make site feature.  Please note that
> >> my comments are from the standpoint of production, and I may
> >> use some "exaggerated" examples.
> >>
> >> As a side note, important for me, is that I have committed our
> >> firm to do all new site development in binarycloud, considering
> >> the state of things as I previously understood the accommodation
> >> of the "problem" of supporting multiple sites.  My concerns are
> >> obviously from this production standpoint.
> >>
> >> My "vision" may be in error, but I previously perceived that there was
> >> a kind of common boiler room with the basic machinery of
> >> BC, and then sub-trees would be branched off, for example,
> >> the ./user directory for modules, libraries or whatever.
> >>
> >> If I now understand it correctly, the aspect of "make site"
> >> now creates a complete stand-alone BC "system".  I perceive
> >> the following problems, and ask for commentary.
> >>
> >> 1.  Module commonality - This aspect was one of the most
> >> attractive aspects of BC, namely, if a calendar module
> >> was developed, it would be accessable from all sites
> >> and there would only be one copy.  Thus, if there was
> >> some minor bug in the module, or some small enhancement
> >> was desired, editing the module IN ONE PLACE would
> >> either correct the problem across all sites, or add
> >> the enhancement across all sites.  If I understand
> >> correctly, now, if this module is in error, the
> >> module would have to be corrected and copied to
> >> all sites that use it.  Obviously, this is something
> >> that is prone to error if you have 100 sites running
> >> with the module.
> >>
> >> 2.  Of lesser concern, as probably this has been accommodated,
> >> but is still is of a concern until I am assured...
> >> This is the scenario, say, of a problem in the future
> >> that is found in, say, the Entity Manager.  Now, with
> >> completly separated site "systems" a CVS has to be run
> >> on all site trees to correct the problem of the Entity
> >> Manager.  Obviously, this is something that is prone
> >> to error, if you have 100 sites running BC.
> >>
> >> 3.  User/Site Class Libraries - I am just uncertain if this is still
> >> being
> >> thought of.  It is more or less the "user's" problem, as
> >> I anticipated that certain class libraries useful for
> >> several sites would be kept somewhere in the single
> >> system tree.  I realize that the PHP search path can
> >> be changed to accommodate this in some other standard
> >> place (i.e. /usr/share/PHP), but I originally wished
> >> to have libraries somewhere in the "single" BC tree.
> >>
> >> 4.  Disk space - This is nit-picking (disk space) in this day and age,
> >> namely
> >> the 600 or whatever files and directories are to be duplicated
> >> for each site.  There is even an argument to "isolate" a
> >> complete site in one tree as something that can be easily
> >> archived.  But, still, imagine that an application is developed
> >> that is a "Volks Kart" shopping cart that is marketed to
> >> mom-an-pop shops and you set it up for a small amount of
> >> money, with BC, and it is a success and you have 1000 in
> >> the region.  Yes, yes, this is exaggerated, but sometimes
> >> it helps to exaggerate to see the point that I wish to
> >> make, namely the loss of the "single system" advantages,
> >> bloating of diskspace usage, and maintenance headaches
> >> that _may_ result from the single-site = complete system
> >> that seemingly is being adopted.
> >>
> >> Does anyone else have these concerns?  Am I understanding this
> >> correctly?
> >>
> >> _justin
> >> --
> >> Justin Farnsworth - Technical Director
> >> Eye Integrated Communications
> >> 321 South Evans - Suite 203
> >> Greenville, NC 27858 | Tel: (252) 353-0722
> >>
> >> _______________________________________________
> >> binarycloud-dev mailing list
> >> bin...@li...
> >> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> >>
> >
> >
> > _______________________________________________
> > binarycloud-dev mailing list
> > bin...@li...
> > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> >
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

Re: [binarycloud-dev] BC Serious Concerns, Production Standpoint

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

have a look at my response :)

> Hey - I've got some things to say about this topic. What you've described is
> actually how I'm doing things now, and I was really interested in switching
> to bc to escape this. Moreso, all of my sites are exactly the same, only
> thing that changes is the information and graphical configuration, which is
> DRASTICALLY different, i.e. - if one user logged in and ended up at the
> wrong site, that would be _really_ bad.
> 
> So in a way, physical location and separate db's are helpful for ensuring no
> data gets mixed up. However, as Justin has pointed out, its makes updating
> functions extremely tedious. There is honestly no need for me to have 50
> copies of sessionauth running. Also, if I add a function to my service, I
> would like to plug it into the central engine and let it work itself out
> from there.
> 
> Is there any way that we can pare this thing down to one set of functions,
> then have different folders/modules for the various sites? The progress
> everyone's been making is truly awesome, but this is a big hang up for me I
> gotta say.
> 
> Alby
> 
> 
> ----- Original Message -----
> From: "Justin Farnsworth" <je...@ey...>
> To: "BINARY_CLOUD" <bin...@li...>
> Sent: Friday, September 07, 2001 12:51 PM
> Subject: [binarycloud-dev] BC Serious Concerns, Production Standpoint
> 
> 
>> Guys:
>> 
>> I have been following silently the shifting sands of BC lately
>> without comment, trying to keep up with the developing trends.
>> 
>> This message may be long, and reflects my understanding of the
>> current file layout and housekeeping related to the make system,
>> and in particular, the make site feature.  Please note that
>> my comments are from the standpoint of production, and I may
>> use some "exaggerated" examples.
>> 
>> As a side note, important for me, is that I have committed our
>> firm to do all new site development in binarycloud, considering
>> the state of things as I previously understood the accommodation
>> of the "problem" of supporting multiple sites.  My concerns are
>> obviously from this production standpoint.
>> 
>> My "vision" may be in error, but I previously perceived that there was
>> a kind of common boiler room with the basic machinery of
>> BC, and then sub-trees would be branched off, for example,
>> the ./user directory for modules, libraries or whatever.
>> 
>> If I now understand it correctly, the aspect of "make site"
>> now creates a complete stand-alone BC "system".  I perceive
>> the following problems, and ask for commentary.
>> 
>> 1.  Module commonality - This aspect was one of the most
>> attractive aspects of BC, namely, if a calendar module
>> was developed, it would be accessable from all sites
>> and there would only be one copy.  Thus, if there was
>> some minor bug in the module, or some small enhancement
>> was desired, editing the module IN ONE PLACE would
>> either correct the problem across all sites, or add
>> the enhancement across all sites.  If I understand
>> correctly, now, if this module is in error, the
>> module would have to be corrected and copied to
>> all sites that use it.  Obviously, this is something
>> that is prone to error if you have 100 sites running
>> with the module.
>> 
>> 2.  Of lesser concern, as probably this has been accommodated,
>> but is still is of a concern until I am assured...
>> This is the scenario, say, of a problem in the future
>> that is found in, say, the Entity Manager.  Now, with
>> completly separated site "systems" a CVS has to be run
>> on all site trees to correct the problem of the Entity
>> Manager.  Obviously, this is something that is prone
>> to error, if you have 100 sites running BC.
>> 
>> 3.  User/Site Class Libraries - I am just uncertain if this is still
>> being
>> thought of.  It is more or less the "user's" problem, as
>> I anticipated that certain class libraries useful for
>> several sites would be kept somewhere in the single
>> system tree.  I realize that the PHP search path can
>> be changed to accommodate this in some other standard
>> place (i.e. /usr/share/PHP), but I originally wished
>> to have libraries somewhere in the "single" BC tree.
>> 
>> 4.  Disk space - This is nit-picking (disk space) in this day and age,
>> namely
>> the 600 or whatever files and directories are to be duplicated
>> for each site.  There is even an argument to "isolate" a
>> complete site in one tree as something that can be easily
>> archived.  But, still, imagine that an application is developed
>> that is a "Volks Kart" shopping cart that is marketed to
>> mom-an-pop shops and you set it up for a small amount of
>> money, with BC, and it is a success and you have 1000 in
>> the region.  Yes, yes, this is exaggerated, but sometimes
>> it helps to exaggerate to see the point that I wish to
>> make, namely the loss of the "single system" advantages,
>> bloating of diskspace usage, and maintenance headaches
>> that _may_ result from the single-site = complete system
>> that seemingly is being adopted.
>> 
>> Does anyone else have these concerns?  Am I understanding this
>> correctly?
>> 
>> _justin
>> --
>> Justin Farnsworth - Technical Director
>> Eye Integrated Communications
>> 321 South Evans - Suite 203
>> Greenville, NC 27858 | Tel: (252) 353-0722
>> 
>> _______________________________________________
>> binarycloud-dev mailing list
>> bin...@li...
>> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>> 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

[IFEROE <IF...@te...>]

Hi again,

I finally got the query_example running. And using the 
query_example.php generated by xml2php. I fixed a few typos in 
query_example.xml.php and discovered that the scalar value error was 
because only one module was defined in the xml file and xml2php didn't 
handle it properly. I've added a new module, and now all works ok. 

Thanks to you and to Andi for your help.

Salva



----- Mensaje Original -----
De: Alex Black <en...@tu...>
Fecha: Viernes, Septiembre 7, 2001 9:42 pm
Asunto: Re: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

> > Hi Salva,
> > 
> >> Nice :-). And no more errors. Seems to me that the first 
> problem > was
> > having 'lang' defined as true in index page but not yet any > 
> language> selected by default, but once selected, all is ok.
> > 
> > Thats a problem in the Langs.xml.php. The XML Tag <is_default> 
> is not right,
> > <flag_default> is interpreted by the Lang class. It's just a 
> mismatch> between the xml def and the Lang class.
> 
> oh.
> 
> I'll commit that.
> 
> I have no problem with is_default.
> 
> > are not displayed. This is a problem to be solved.
> 
> I think we might need to hook that stuff up to PEAR_Error.
> 
> _a
> 
> > Try to echo error messages in QueryManager manually 
> (PrepareConnection()> method) to see whats going wrong.
> > 
> >>  Right now its:
> >>  <IncludePath>>BC_PATH."ext/metabase"</IncludePath>.
> > 
> > Right would be <IncludePath>BC_PATH."/ext/metabase"</IncludePath>.
> > 
> >> It seems that '.' after BC_PATH is not translated to "/" in
> >> win32, so
> > so it isnt on Unix. Its a string append operator. It like
> > 
> > $string .= "String2"
> > 
> > The error is the missing / in the defintion file
> > 
> >> Warning: Cannot use a scalar value as an array in
> >> G:/CYGWIN/BC/R2/BINARYCLOUD/build/en/binarycloud/core/Page.php
> >> on line 161
> > 
> > That's because XML2PHP does not behave right. The translation of 
> Page> Definitions is faulty. Again, manually copy the files from 
> the source tree.
> > 
> >> I give up by the moment ;-). Well, after all, I'm working
> >> with CVS code, so things like this are normal.
> > 
> > I've much stress at the moment so I don't have much time for bc. 
> I'll fix
> > all this in the middel of next week.
> > 
> > 
> >> PS: I will try to test it with IIS 5.0. If I do, I will send to 
> > this
> > list what I found.
> > 
> > Cool. Looking forward to hear the results..
> > 
> > 
> > Andi
> > 
> > 
> > _______________________________________________
> > binarycloud-dev mailing list
> > bin...@li...
> > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> > 
> 
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

 ___________________________________________________________________ 
Consigue tu e-mail gratuito TERRA.ES
 Haz clic en http://www.terra.es/correo/

Re: [binarycloud-dev] BC Serious Concerns, Production Standpoint

[Albert L. <a.l...@ve...>]

Hey - I've got some things to say about this topic. What you've described is
actually how I'm doing things now, and I was really interested in switching
to bc to escape this. Moreso, all of my sites are exactly the same, only
thing that changes is the information and graphical configuration, which is
DRASTICALLY different, i.e. - if one user logged in and ended up at the
wrong site, that would be _really_ bad.

So in a way, physical location and separate db's are helpful for ensuring no
data gets mixed up. However, as Justin has pointed out, its makes updating
functions extremely tedious. There is honestly no need for me to have 50
copies of sessionauth running. Also, if I add a function to my service, I
would like to plug it into the central engine and let it work itself out
from there.

Is there any way that we can pare this thing down to one set of functions,
then have different folders/modules for the various sites? The progress
everyone's been making is truly awesome, but this is a big hang up for me I
gotta say.

Alby


----- Original Message -----
From: "Justin Farnsworth" <je...@ey...>
To: "BINARY_CLOUD" <bin...@li...>
Sent: Friday, September 07, 2001 12:51 PM
Subject: [binarycloud-dev] BC Serious Concerns, Production Standpoint


> Guys:
>
> I have been following silently the shifting sands of BC lately
> without comment, trying to keep up with the developing trends.
>
> This message may be long, and reflects my understanding of the
> current file layout and housekeeping related to the make system,
> and in particular, the make site feature.  Please note that
> my comments are from the standpoint of production, and I may
> use some "exaggerated" examples.
>
> As a side note, important for me, is that I have committed our
> firm to do all new site development in binarycloud, considering
> the state of things as I previously understood the accommodation
> of the "problem" of supporting multiple sites.  My concerns are
> obviously from this production standpoint.
>
> My "vision" may be in error, but I previously perceived that there was
> a kind of common boiler room with the basic machinery of
> BC, and then sub-trees would be branched off, for example,
> the ./user directory for modules, libraries or whatever.
>
> If I now understand it correctly, the aspect of "make site"
> now creates a complete stand-alone BC "system".  I perceive
> the following problems, and ask for commentary.
>
> 1.  Module commonality - This aspect was one of the most
> attractive aspects of BC, namely, if a calendar module
> was developed, it would be accessable from all sites
> and there would only be one copy.  Thus, if there was
> some minor bug in the module, or some small enhancement
> was desired, editing the module IN ONE PLACE would
> either correct the problem across all sites, or add
> the enhancement across all sites.  If I understand
> correctly, now, if this module is in error, the
> module would have to be corrected and copied to
> all sites that use it.  Obviously, this is something
> that is prone to error if you have 100 sites running
> with the module.
>
> 2.  Of lesser concern, as probably this has been accommodated,
> but is still is of a concern until I am assured...
> This is the scenario, say, of a problem in the future
> that is found in, say, the Entity Manager.  Now, with
> completly separated site "systems" a CVS has to be run
> on all site trees to correct the problem of the Entity
> Manager.  Obviously, this is something that is prone
> to error, if you have 100 sites running BC.
>
> 3.  User/Site Class Libraries - I am just uncertain if this is still
> being
> thought of.  It is more or less the "user's" problem, as
> I anticipated that certain class libraries useful for
> several sites would be kept somewhere in the single
> system tree.  I realize that the PHP search path can
> be changed to accommodate this in some other standard
> place (i.e. /usr/share/PHP), but I originally wished
> to have libraries somewhere in the "single" BC tree.
>
> 4.  Disk space - This is nit-picking (disk space) in this day and age,
> namely
> the 600 or whatever files and directories are to be duplicated
> for each site.  There is even an argument to "isolate" a
> complete site in one tree as something that can be easily
> archived.  But, still, imagine that an application is developed
> that is a "Volks Kart" shopping cart that is marketed to
> mom-an-pop shops and you set it up for a small amount of
> money, with BC, and it is a success and you have 1000 in
> the region.  Yes, yes, this is exaggerated, but sometimes
> it helps to exaggerate to see the point that I wish to
> make, namely the loss of the "single system" advantages,
> bloating of diskspace usage, and maintenance headaches
> that _may_ result from the single-site = complete system
> that seemingly is being adopted.
>
> Does anyone else have these concerns?  Am I understanding this
> correctly?
>
> _justin
> --
> Justin Farnsworth - Technical Director
> Eye Integrated Communications
> 321 South Evans - Suite 203
> Greenville, NC 27858 | Tel: (252) 353-0722
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

Re: [binarycloud-dev] make'd site file structure

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

> 
> Ok, a few more questions come to mind.
> 
> If I write my core BEFORE I make, this implies that parts of the "source
> tree" need to be accessible by the webserver.  (bindly coding PHP is no
> fun)

No, you run make for changes.
So, modify a file, run make, test.
Make will be quick because it compares fie modification dates.

> When you say "write my code", I assume you mean writing modules.  For
> creating the templates, page definitions, web site directory structure,
> etc requires an existing document root.  It makes sense to me that I can
> simply 'make site_name', then go to my newly make'd site tree, and begin
> coding.

You don't write code in your build directory, you write it in your source
tree. So for example, you'd write some code in
r2/binarycloud/user/site_name/mod/ModuleName.php, and run make.

the webserver would "see" r2/binarycloud/build/en/htdocs/* in a development
environment, probably usr/local/apache/htdocs/en/ in a production
environment.

> Where would my virtual host document point?
> - bc/build/en/site_name
> - /var/www/html/site_name (symlink to bc/build/en/site_name)
> - whatever

Yes.

_a


> ok, that's all i can muster for now..
> jason
> 
> 
> 
> 
> 
> 
> 
> Alex Black wrote:
>> Think of it as:
>> 
>> "source tree" (the place where you write your code)
>> make -> "binary" which is in our case a collection of files which are
>> specifically configured to work with that language context, etc.
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
> 

Re: [binarycloud-dev] make'd site file structure

[Jason H. <jc...@ey...>]

Ok, a few more questions come to mind.

If I write my core BEFORE I make, this implies that parts of the "source
tree" need to be accessible by the webserver.  (bindly coding PHP is no
fun)

When you say "write my code", I assume you mean writing modules.  For
creating the templates, page definitions, web site directory structure,
etc requires an existing document root.  It makes sense to me that I can
simply 'make site_name', then go to my newly make'd site tree, and begin
coding.

Where would my virtual host document point?
	- bc/build/en/site_name
	- /var/www/html/site_name (symlink to bc/build/en/site_name)
	- whatever

ok, that's all i can muster for now..
jason







Alex Black wrote:
> Think of it as:
> 
> "source tree" (the place where you write your code)
> make -> "binary" which is in our case a collection of files which are
> specifically configured to work with that language context, etc.

Re: [binarycloud-dev] BC Serious Concerns, Production Standpoint

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

> My "vision" may be in error, but I previously perceived that there was
> a kind of common boiler room with the basic machinery of
> BC, and then sub-trees would be branched off, for example,
> the ./user directory for modules, libraries or whatever.

That's essentially correct. Though we'll need to build in a little path-fu
for the make system that will allow us to easily switch between
language-build versions of the binarycloud core classes.

I.e. if you're sharing the bc-core classes, you need to be able to easily
switch from en/binarycloud to fr/binarycloud in that central store.

> If I now understand it correctly, the aspect of "make site"
> now creates a complete stand-alone BC "system".  I perceive
> the following problems, and ask for commentary.

That's correct.

> 1.  Module commonality - This aspect was one of the most
> attractive aspects of BC, namely, if a calendar module
> was developed, it would be accessable from all sites
> and there would only be one copy.  Thus, if there was
> some minor bug in the module, or some small enhancement
> was desired, editing the module IN ONE PLACE would
> either correct the problem across all sites, or add
> the enhancement across all sites.  If I understand
> correctly, now, if this module is in error, the
> module would have to be corrected and copied to
> all sites that use it.  Obviously, this is something
> that is prone to error if you have 100 sites running
> with the module.

No, it isn't.

You would modify your original files in default/ or common/ or whatever you
want to call it, and run make again, which would propagate your change to
all of your individual site installs.

That's the purpose of the make system - i.e. to maintain a single tree of
source, and then build different flavors of that source tree:

Maybe for one server, you need to have your code run through zend encoder.
Maybe for another, you want to have a 'complete package' (i.e. all
binarycloud code) for each site
Maybe for another you wan to share a single repository because you're
hosting 50 sub-sites, etc.

> 2.  Of lesser concern, as probably this has been accommodated,
> but is still is of a concern until I am assured...
> This is the scenario, say, of a problem in the future
> that is found in, say, the Entity Manager.  Now, with
> completly separated site "systems" a CVS has to be run
> on all site trees to correct the problem of the Entity
> Manager.  Obviously, this is something that is prone
> to error, if you have 100 sites running BC.

Not 100 sites, 100 _servers_.

But that has nothing to do with binarycloud: if you are managing a
homogenous codeset across a number of machines, and make a change to the
code in your central repository, of course you will have to propagate that
change throughout your cluster.

If you are running a single machine with many sites, you'll be able to set
it up so you share all bc core classes, so you'd only have to sync 1 file.

> 3.  User/Site Class Libraries - I am just uncertain if this is still
> being
> thought of.  It is more or less the "user's" problem, as
> I anticipated that certain class libraries useful for
> several sites would be kept somewhere in the single
> system tree.  I realize that the PHP search path can
> be changed to accommodate this in some other standard
> place (i.e. /usr/share/PHP), but I originally wished
> to have libraries somewhere in the "single" BC tree.

That will be supported.

I discussed this a while ago, i.e. the idea of a 'default' site tree which
will be compared to each site tree as it is being made - for files that are
missing in the current site, but present in the default site, we'll copy
them over and install them as if they were a part of the current site.

That means you can share configuration between 45 of 50 sites, and for the 5
that need special configuration, write a configuration files.

> 4.  Disk space - This is nit-picking (disk space) in this day and age,
> namely
> the 600 or whatever files and directories are to be duplicated
> for each site.  There is even an argument to "isolate" a

That won't be the case. With a shared bc-core, you'll only have to copy site
specific files.

of course none of the stuff that I have mentioned above is _done_: if you'd
like to start hacking to make it work, I would welcome your commits.

> complete site in one tree as something that can be easily
> archived.  But, still, imagine that an application is developed
> that is a "Volks Kart" shopping cart that is marketed to
> mom-an-pop shops and you set it up for a small amount of
> money, with BC, and it is a success and you have 1000 in
> the region.  Yes, yes, this is exaggerated, but sometimes
> it helps to exaggerate to see the point that I wish to
> make, namely the loss of the "single system" advantages,
> bloating of diskspace usage, and maintenance headaches
> that _may_ result from the single-site = complete system
> that seemingly is being adopted.
> 
> Does anyone else have these concerns?  Am I understanding this
> correctly?     

Not really: you're looking at the _current_ system, not the designs I've put
up on the list.

Everything you originally brought up, with a few modifications is in the
todo. I intend to support as many strange permutations of make config as
possible, but it all depends on who is willing to contribute what.

If you want something in the make system, please check with me first to
compare design notes, but other than that feel free to hack the make system
to add configuration options for whatever kinds of setups you would like.

Everything you mention above is going to be in the roadmap document I'm
almost done with, btw.


best,

_alex

Re: [binarycloud-dev] Binarycloud on WinNT, IIS, PHP4, MySQL

[Ronald T. <ron...@ho...>]

2001 11:52:41 +0200
>
>Hi folks,
>
>did someone successfully run binarycloud on the windows platform?
>
>Especially:
>
>WinNT/2k
>IIS 5
>PHP4
>MySQL 3.xx
>
>I mean not running make, but the the maked binarycloud on the webserver?
>
>Any drawbacks, problems or specialities (except using driveletters in 
>paths)
>?
>
>
>Andi
>
hi all,

actually everytime when the new version comes out, I will test on both 
Apache
and IIS in Win32 platform, and besides those problem which appera in all 
platform there is no specific problem which just appear in IIS with all 
example come with BC.

roni

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

[binarycloud-dev] BC Serious Concerns, Production Standpoint

[Justin F. <je...@ey...>]

Guys:

I have been following silently the shifting sands of BC lately
without comment, trying to keep up with the developing trends.

This message may be long, and reflects my understanding of the
current file layout and housekeeping related to the make system,
and in particular, the make site feature.  Please note that
my comments are from the standpoint of production, and I may
use some "exaggerated" examples.

As a side note, important for me, is that I have committed our
firm to do all new site development in binarycloud, considering
the state of things as I previously understood the accommodation
of the "problem" of supporting multiple sites.  My concerns are
obviously from this production standpoint.

My "vision" may be in error, but I previously perceived that there was
a kind of common boiler room with the basic machinery of
BC, and then sub-trees would be branched off, for example,
the ./user directory for modules, libraries or whatever.

If I now understand it correctly, the aspect of "make site"
now creates a complete stand-alone BC "system".  I perceive
the following problems, and ask for commentary.

1.  Module commonality - This aspect was one of the most
	attractive aspects of BC, namely, if a calendar module
	was developed, it would be accessable from all sites
	and there would only be one copy.  Thus, if there was
	some minor bug in the module, or some small enhancement
	was desired, editing the module IN ONE PLACE would
	either correct the problem across all sites, or add
	the enhancement across all sites.  If I understand
	correctly, now, if this module is in error, the
	module would have to be corrected and copied to
	all sites that use it.  Obviously, this is something
	that is prone to error if you have 100 sites running
	with the module.

2.  Of lesser concern, as probably this has been accommodated,
	but is still is of a concern until I am assured...
	This is the scenario, say, of a problem in the future
	that is found in, say, the Entity Manager.  Now, with
	completly separated site "systems" a CVS has to be run
	on all site trees to correct the problem of the Entity
	Manager.  Obviously, this is something that is prone
	to error, if you have 100 sites running BC.

3.  User/Site Class Libraries - I am just uncertain if this is still
being
	thought of.  It is more or less the "user's" problem, as
	I anticipated that certain class libraries useful for
	several sites would be kept somewhere in the single
	system tree.  I realize that the PHP search path can
	be changed to accommodate this in some other standard
	place (i.e. /usr/share/PHP), but I originally wished
	to have libraries somewhere in the "single" BC tree.

4.  Disk space - This is nit-picking (disk space) in this day and age,
namely
	the 600 or whatever files and directories are to be duplicated
	for each site.  There is even an argument to "isolate" a
	complete site in one tree as something that can be easily
	archived.  But, still, imagine that an application is developed
	that is a "Volks Kart" shopping cart that is marketed to
	mom-an-pop shops and you set it up for a small amount of
	money, with BC, and it is a success and you have 1000 in
	the region.  Yes, yes, this is exaggerated, but sometimes
	it helps to exaggerate to see the point that I wish to
	make, namely the loss of the "single system" advantages,
	bloating of diskspace usage, and maintenance headaches
	that _may_ result from the single-site = complete system
	that seemingly is being adopted.

Does anyone else have these concerns?  Am I understanding this
correctly?     

_justin 
-- 
Justin Farnsworth - Technical Director
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722