binarycloud-dev — development list for binarycloud

Re: [binarycloud-dev] Awwww man, facility, not policy!!!

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

Alby:

Thank you for your concern about my health.  Don't worry,
the FBI Witness Protection Program is so efficient.  I
am such a hot number that they have put me up in the
orbiting space station.  So, those time stamps rotate
at Schuler Pendulum periods, 24, count 'em, every
82 minutes....


-------------------------

Alby Lash wrote:
> 
> Hey Justin,
> 
> You've been drinking too much coffee man, I thought I was bad getting up at
> 4:30am, starting work at 7, then finishing at 9:30pm.
> 
> You've got me beat: a post on Friday night @ 10:30pm; then another @ 6:50am,
> on SATURDAY! Take it easy man, don't burn out!
> 
> Alby Lash
> al...@th...
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

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

Re: [binarycloud-dev] Another kneejerk suggestion for import()

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

Andreas:

Hey, I can live with that.  It makes the distinction
that I was wanting, would have sufficient information
in it for import() to allow me to have "dots" in
my file names, I think.

And, of course, you are correct about the economy
of a single call to "load a package" without
have to worry about that package's inventory/names
changing from underneath you.  Yes, I like that.

Right now, I am a bit confused, because I don't know
what the intentions of Alex are, and if this would
fit in the grand schems.  It seems to me, however,
that your idea is good, and aligns itself with what
Alex is thinking.  I also like your syntax better
than what I suggested as a kneejerk, that is, your
syntax only requires one argument to import().
That is better.

It still won't allow me, I think, to name my
layout files *.layout, my masters *.master, and
so forth.  Somehow, I still would like to retain
that possibility.  I also still feel that within
the system, for the only example that Alex/Odysseas
gave where *.php is "necessary", like using
the filter xml2php, there could be a solution.
That solution would be to put a "wrapping environment"
around those operations by, say, appending ".php"
before the operation, and stripping ".php" after
the operation.

Sure, this adds some overhead, but it is trivial.
Right now, you cannot even have your files named
*.PHP, or *.phtml, which is functionally identical
to *.php, but gives my "need" a bit more force.
Lordy, I hate the idea that, right now, I cannot
name my files

	*.layout

or as a partial compromise

	*.layout.php

because it throws away the ability of easily
constructing find(1) scripts or globbed
arguments to any argument to any of the
standard UNIX/Linux utilities needed for
easy administration.  If I had to do things
like name my files:

	file01Layout.php
	file07Master.php
	file09Module.php

and the go sed(1) everywhere in my scripts,
I would get very tired and irascable.  Er,
I am already tired and irascable... 

Again, I like your suggestion.

_jef

------------------------------------

Andreas Aderhold wrote:
> 
> Hi Justin,
> 
> > What about this syntax to ship enough information to
> > import() in order to distinguish "package" from "file":
> > import('a_file_name')
> > for importing a "true file object", and
> > import('package_name:object')
> > for importing an "object" from a "package"????
> 
> Another one could be:
> 
> Leave import for packages as is:
> import('binarycloud.core');
> import('binarycloud.core.Init);
> etc.
> 
> add resource handler for true files:
> 
> import('file:a_file_name');
> 
> .andi
> 
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

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

Re: [binarycloud-dev] Awwww man, facility, not policy!!!

[Alby L. <al...@th...>]

Hey Justin,

You've been drinking too much coffee man, I thought I was bad getting up at
4:30am, starting work at 7, then finishing at 9:30pm.

You've got me beat: a post on Friday night @ 10:30pm; then another @ 6:50am,
on SATURDAY! Take it easy man, don't burn out!

Alby Lash
al...@th...

RE: [binarycloud-dev] Another kneejerk suggestion for import()

[Andreas A. <a.a...@th...>]

Hi Justin,

> What about this syntax to ship enough information to
> import() in order to distinguish "package" from "file":
> import('a_file_name')
> for importing a "true file object", and
> import('package_name:object')
> for importing an "object" from a "package"????

Another one could be:

Leave import for packages as is:
import('binarycloud.core');
import('binarycloud.core.Init);
etc.

add resource handler for true files:

import('file:a_file_name');


.andi

RE: [binarycloud-dev] Warts on import() - bis

[Andreas A. <a.a...@th...>]

Hi,

> And then in the top of index.php, put these lines:
> import('../../../bullshit');
> exit;

I think import() is not meant to handle path/fileinformation directly. What
you described is a side effect of import caus dots are translatet to / and
this way the import contains a meta info. But this might not be neccessarily
a path. (this should be fixed, disallow "/", "\" and .+).

The idea of import is a system to simplify including, I think (correct me if
I'm wrong):

E.g.: import('binarycloud.pear');

instead of:
include_once(BC_PATH."/ext/pear/PEAR.php");
include_once(BC_PATH."/ext/pear/cache.php");
include_once(BC_PATH."/ext/pear/whatever.php");
include_once(BC_PATH."/ext/pear/stuff.php");

The import() includes all neccessary files related to pear (or alle
neccesary files of pear you need to include by calling import(bc.pear), or
all files in the ext/pear/ directory or....). Imagine you have to include
all by hand and then some filenames change within pear, you have to edit all
your code where you include pear. With import, nothing changes.

Ok, you could do it the common way. But with a growing codebase the package
thing is more flexible, clear and intuitive, in my opinion.
And imagine it's required that individual tasks have to be perfomed by
including a specific package. If so you dont have to care about this, just
import package and thats it.

Andi

[binarycloud-dev] Another kneejerk suggestion for import()

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

Alex:

I feel like I am bombarding you today...

What about this syntax to ship enough information to
import() in order to distinguish "package" from "file":

	import('a_file_name')

	for importing a "true file object", and

	import('package_name:object')

	for importing an "object" from a "package"????

See, this would suit me.  Maybe not everybody.  I NEVER
USE A COLON in file names.  Somebody might.  But, I
would argue that in the great corpus of UNIX conventions,
using dots in file names probably prevails over using
colons in file names by at least 100 to 1.  Hell, I
don't really know that, but I bet you agree...

Boff.  I am stopping now with this struggling with
this problem for the time being and go make my modules
work on the new r2, and wait for you to get out of
bed and respond.  Maybe you have already fixed the
problem in your dreams out there in PST.

_jef

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

[binarycloud-dev] Warts on import() - bis

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

Alex:

Your import() is broken in any case.  You sent a dot when
you should have sent a man.

If I, for debugging purposes, change prepend.php as:

function import($_file) {
        global $sImportMap;
        if ($sImportMap[$_file]) { return true; }

        global $gImportPaths;
        // at some point we should extend this to enable a list of
import paths
        $gImportPaths = array(BC_PATH);

        $path = strtr($_file, '.', '/') . '.php';
        foreach ($gImportPaths as $prefix) {
printf("INCLUDED: %s<br>","$prefix/$path"); //<=== DEBUG
                if (include_once("$prefix/$path")) {
                        $sImportMap[$_file] = true;
                        return true;
                }
        }
        return false;
}

And then in the top of index.php, put these lines:

import('../../../bullshit');
exit;

the result is:
------------------------------------------
INCLUDED: /usr/local/binarycloud/build/en//////////bullshit.php

Warning: Failed opening
'/usr/local/binarycloud/build/en//////////bullshit.php' for inclusion
(include_path='.:/usr/share/php') in ./prepend.php on line 34
------------------------------------------------

Now Alex, you don't want THAT, do you?  You are not going to
force policy of NEVER using relative directories, are you?
Of course not, I hope.

OK, I am not afraid of being laughed at for thinking out loud,
so I have been thinking about "what you want to do" with this
"package" idea, and the conventions you need to use for this,
and how import() can be smarter.

If import() is supposed to handle the abstraction of working
for importing files, and/or "packages", and/or certain files
from certain packages, ya gotta give import() more information.

I think you should think about trying something like:

	import($_arg,$package=null)

and then, cumbersome as it first appears, have the calling
syntax require, if it is an "abstraction" from a package,
call it thus:

	import("something_that_is_a_standalone_file")

	for a true file, and:

	import("something_related_to_package","package_name")

	for a "file" that is in the abstraction "package_name".

You would have enough information available to import() to then
be able to parse things and come out with the ultimate correct
file to include_once().

You might even wish to establish another global map to have
tuples of "package" and "filename" held.  I don't know where
you are going to go with those maps, I _do_ see their utility
and efficiency of cutting down on useless calls to PHP that
you know in advance are going to fail and burn up CPU time.

This is _only_ a quickie suggestion.  I have no inkling if this
would fit in with your ideas.

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

[binarycloud-dev] Stripping comments in build

[Andreas A. <a.a...@th...>]

Hi,

is it planned to strip comments from the .php files within the build tree? I
think that should be done to reduce parsing time.

.andi

RE: [binarycloud-dev] FW: GroupIT Engine

[Andreas A. <a.a...@th...>]

Agreed. GroupIT is more or less for applications of a specific category, as
PHPNuke, phpgroupware, phpwhatever are. BC is more flexible, the code more
reusable and more well planned, I think. Had a breif look over the code and
it looks like one of these applications that are not planned before coding.
You know, someone came up with an idea starting to code immediately and
giving the best shot modifieing and extending at will while the application
grows. No real concept before starting to code, no system design.
Well thats was my first impression when I looked over the code. But I have
to admitt that the code is much better than many other php stuff around (and
there is _very_ much jiberish around). BC is the best designed and coded php
"app" I've seen so far.

Andi


-----Original Message-----
Jimmy Harlindong wrote:
>
> Alex,
>
> Will BC be as cool as GroupIT? I just saw their sample site thumbnails
> and it looks nice (of course it's just 'looks') hehe
[== snip, snip ==]

...

RE: [binarycloud-dev] RE: r2 /make

[Andreas A. <a.a...@th...>]

Hi Alex,

>> r2/binarycloud/build/binarycloud/
>> r2/binarycloud/build/htdocs/
>> Why that ?
> because
> /path/to/r2/binarycloud/base/*
> is the source tree, it is not used in production.
ok, thats clear

> if you look in build/en/binarycloud/* you'll notice that the organization
is
> different.
Yepp. But I don't get it right now how the build arch is handled with the
webserver config.

If I understand right the language rips are completly standalone systems.
Thats good and no problem if you have different docroots/vhosts vor each
language. e.g.

foo.com points to build/htdocs/  -> determines language and switches to
en.foo.com points to build/en/htdocs or
de.foo.com points to build/en/htdocs
etc.

but what if you want to have language switching capabilities within one site
e.g. foo.com and foo.de points to the same docroot:

foo.com -> derminte language and set internally
user switches foo.com?.lang=de

or another organization:
foo.com/de/
foo.com/en/

How is this handled within the build-tree. I only want the htdocs directory
accessible by the user. The directories above should be out ouf user scope.

Maybe this is a stupid question and I'm missing something obvious. But I
don't get it right now :-(

.andi


--
When we eliminate the impossible, whatever remains,
however improbable, must be true. -- Sherlock Holmes

Re: [binarycloud-dev] FW: GroupIT Engine

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

Jimmy Harlindong wrote:
> 
> Alex,
> 
> Will BC be as cool as GroupIT? I just saw their sample site thumbnails
> and it looks nice (of course it's just 'looks') hehe
[== snip, snip ==]

For what it is worth, I have not looked in detail at this GroupIT.
One of my programmers, Jason Hines, has.  Jason is the author of
PhpWebLog and some other thingy's on sourceforge, is a genius
programmer in my estimation, and I trust his opinion.

Jason says that GroupIT is more of an application that is, indeed,
very slick, allows one to construct sites from a higher
abstraction level.  However, it is not what we want, namely
a kind of development environment that solves a lot of
common "problems".

Jason says that BC is (potentially) better for speeding up
development, code reuse, administration, Lego-izing the
world -- than GroupIT.  Maybe the way to describe this is
that GroupIT _may_ allow a secretary construct a slick
site, but it leaves everything a mess underneath.

Like I said, I have not looked personally at GroupIT.
From what I did see, and Jason's perusal, the vision
and concept of BC is far more attractive than GroupIT
for those people that want to be able to construct
_many_ sites reliably and quickly and have what is left
underneath reusable and easy to administrate.

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

[binarycloud-dev] File Extensions: My bark is worse than my byte...

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

Alex/Odysseas:

[off topic]
Odysseas, is your wife/girlfriend/SO named Penelope?

[topic]
It is good to see that the reason for the current mechanism
of forcing .php (but not .PHP) extensions is for noble reasons, i.e.,
for
the Java-like package thingy.  And, I also understand that
some of the background utilities like xml2php requires
extension determination, cause there ain't no way to look
at MAGIC_NUMBERS in text files or imbed artificial intelligence
into these utilities, and look inside before leaping.

OK, what can we do here?  You also must realize that the
present mechanism prevents me from using dots in file
names.  I will have, say, an additional problem that
may be useful to describe as I would hope that it
could be accommodated.  Here, Les Artistes (our design
department), being goog Mac users, like to give me
files that have names like:

	"The picture of Julie with a red dress"
	"jpeg of Julie with Daisy Dukes"

and I at least got them to do

	"The.picture.of.Julie.with.a.red.dress"

instead.

So, with BC, I could imagine in development Les Artistes
give me 10 layouts for some page that we must make a decision
on, like:

	Jean-Pierre.1.layout
	Jean-Pierre.2.layout
	Jean-Pierre.3.layout
	|

and we gather around to test them to make a choice.  I
have to either rename the files, or symbolic link each
one of them  file->test.php, one by one.

So, even if I train Les Artists to give me

	Jean-Pierre.1.layout.php
	Jean-Pierre.2.layout.php
	Jean-Pierre.3.layout.php

it ain't gonna work.  This conforms to the "specification"
denoted by Odysseas, viz:

--quote--
The package/import notation and functionality is
mimicking the package/import of java/perl etc.
As you have guessed, this feature puts an additional
requirement for a single source code extension.
--unquote--

but, friends, your import() would still choke on
it too...  So, this "requirement" is sort of
disingenuous, as the above set "conforms" but
doesn't work in these circumstances.

I could impose a Java-like, initial caps nomenclature
like:
	FileLayout1.php
	FileLayout2.php

which would work, but I too, would like to use the
old dot in the old fashion in the old way, cause I
may have a script or a Makefile that looks for
/*.layout$/, or /*.layout.*/ and does something with
this collection.

There has to be a way out of this.  I think your
conception of using "packages" is a good thing.
Hmm, I will have to think about how to do it,
while still allowing my beloved dots to be used
in filenames as fields that reflect some kind of
important information.class.use.owner.whatever.
The design assumption of mapping "dot" as a
one to manyUses is the basic "problem" here.
Now, a quick solution would be:

        'templates' => array(
                'def' => array(
                        'name' => "|Jean-Pierre.1.layout",
                        'package' => "html.masters",
                        'type' => "html",
                ),
                'other' =>  array(
                        'name' => "|Jean-Pierre.2.layout",
                        'package' => "html.masters",
                        'type' => "html",
                )

to use the pipe "|" to have import() know when the path
ends and the file begins.  BUT THIS IS RATHER UGLY.  I
allege that you probably have enough information already
to somehow work around.  YOU KNOW right now that in the
$bc_page hash,  what is in ['name'] IS A FILE, but without
the .php extension.

Like all insecure authors, I will leave the solution up
to the reader....

I'll come back to youse guys if I think of something
general and elegant.

Regards,
_jef


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

Re: [binarycloud-dev] r2 make system win32 step by step

[TAO R. <ron...@ho...>]

> > hi all,
> >
> > I just test the r2 make system in my win32 box, and it works very fine,
> > try the following step,
>
>no s*it?
>you rule, ronald.
nothing messy...... haha :)
>
> > 1. go to http://sources.redhat.com/cygwin/ install the latest cygwin
> > package.
> > 2. download the win32 version of PHP for http://www.php.net/
> > 3. unpack the r2 package in the cygwin environment.
> > 4. set the environment variable BCHOME=c:/path/to/binarycloud
> > 5. edit BCHOME/base/utils/installcode.sh, add #!/bin/sh in the first 
line
> > 6. edit BCHOME/base/utils/processprepend.php and xml2php.php, replace 
the
> > first
> >    line with #!c:/path/to/php/php.exe -q
> > 7. then let's make, and it should be fine....... :)
> >
> > have fun :)
>
>I'll include your instructions in the manual.... excellent!
>
>_alex
that's great...
but it's better someone try on it, and report the problem.....

ronald
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [binarycloud-dev] r2 make system win32 step by step

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

> hi all,
>
> I just test the r2 make system in my win32 box, and it works very fine,
> try the following step,

no s*it?
you rule, ronald.

> 1. go to http://sources.redhat.com/cygwin/ install the latest cygwin
> package.
> 2. download the win32 version of PHP for http://www.php.net/
> 3. unpack the r2 package in the cygwin environment.
> 4. set the environment variable BCHOME=c:/path/to/binarycloud
> 5. edit BCHOME/base/utils/installcode.sh, add #!/bin/sh in the first line
> 6. edit BCHOME/base/utils/processprepend.php and xml2php.php, replace the
> first
>    line with #!c:/path/to/php/php.exe -q
> 7. then let's make, and it should be fine....... :)
>
> have fun :)

I'll include your instructions in the manual.... excellent!

_alex

[binarycloud-dev] r2 make system win32 step by step

[TAO R. <ron...@ho...>]

hi all,

I just test the r2 make system in my win32 box, and it works very fine,
try the following step,

1. go to http://sources.redhat.com/cygwin/ install the latest cygwin 
package.
2. download the win32 version of PHP for http://www.php.net/
3. unpack the r2 package in the cygwin environment.
4. set the environment variable BCHOME=c:/path/to/binarycloud
5. edit BCHOME/base/utils/installcode.sh, add #!/bin/sh in the first line
6. edit BCHOME/base/utils/processprepend.php and xml2php.php, replace the 
first
   line with #!c:/path/to/php/php.exe -q
7. then let's make, and it should be fine....... :)

have fun :)

ronald

Ronald TAO
ron...@ho...

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [binarycloud-dev] Awwww man, facility, not policy!!!

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

> As we are evolving BC towards the more makefile-driven
> r2, we decided to standardize the various file type
> extensions:
> Makefiles need standard extensions so as there
> are standard rules that can do one thing for one type
> of a file and a different thing for another type of a
> file. That's why if you write your C application
> you are stuck ending all your files with .c etc etc.

I suppose you could enable some sort of "file translation directory" as an
include for the make system - where if a user wants to say ".master = .php",
they can.

I don't particularly love that, but I believe it would work, no?

> The packaging feature become a necessity
> as you move from small software projects to big ones.
> Languages that were built from the begining for large
> scale programming, like Java, had that feature from
> birth.

This is an important point. We're talking about managing a very large
codebase, and working with that codebase in development.

In my first version of Page, there were includes - and those includes were
path based and a little kludgey.

Now those includes are imports, and they are structured, clean, and
readable.

If we're going to use external libraries of code like Pear, Metabase, etc we
need a way to handle updates, etc to those - and I would prefer not to deal
with having to update include_once statements all over the place. Packages
make everything a hell of a lot cleaner.

Also, by standardizing filenames, we can do things like allow you to have
entities in module directories in the source tree, but make sure all the
entities are in one place in the build version.

All of that is only possible if we can have some implicit knowledge about
the files in the make system. I can imagine that 'filename' directory, but
at the same time that's a maintenance headache for whoever is doing
development. But that may be the solution.

> Languages like perl, in their original versions
> allowed any extension and lacked the packaging
> functionality. As the perl applications became deeper
> and deeper the packages were introduced. To use the
> packages you had to name your files *.pm .
> In some ways PHP is like perl in its infancy. Projects
> like BC are trying to enable its use not only for
> web-site-making but also for more heavy duty web
> applications and in that sense are forced to make use
> of some of these more "advanced" features.

yepp

_alex

Re: [binarycloud-dev] Awwww man, facility, not policy!!!

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

I think I should make this clear, so everyone know how this is going to
happen:

The releases I am doing right now of r2 are, while functional, almost
experimental. I'm playing. Nothing major will change, in the sense that I
don't intend to rename the project "CowPharm" and change the directory
structure :) - but at the same time all these early CVS snaps are just that:
pictures of a moving target.

These releases are not meant to be even remotely final, i.e. they are not
rigid statements about "how it will be" - they are "how it is now, but it
could change!"

So, this is not about policy, I don't ship policy. All of this stuff is
moving, and when we're done it will accomodate almost any changes, strange
configs, etc that everyone needs.

For the moment I'm concerned with getting a working system, even if it lacks
a few things - so we can take that and add flexibility and power.

I am being _extremely_ careful not to design in any restrictions - not to
say that there aren't assumptions in the current cvs snapshots (as Justin's
previous mail points out) - but to say that there _will_not_ be high level
assumptions unless there _absolutely_must_be_ to have a functioning system.

i.e. we all have to agree that modules are loaded by Page - but not
necessarily how to always name files, or how to run your make + development
process.

In the end all of this back and forth, and _early_ exposure to the community
(i.e. all of you) will help me judge how to proceed. It's extremely helpful,
and I thank you all for it. (Keep on crackin' the whip, justin :)

_alex

Re: [binarycloud-dev] FW: GroupIT Engine

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

> Alex,
>
> Will BC be as cool as GroupIT? I just saw their sample site thumbnails
> and it looks nice (of course it's just 'looks') hehe

for the moment I will not blare loudly this, but: yes.

> Come on alex I need BC! :)

all in good time, I want this second one to really be the shit :)

> Ohh btw you are not going to sell BC like GroupIT are you? I hope not
> hehe


God no, but I will use it in projects for my company, for obvious reasons :)

_alex





>
> > -----Original Message-----
> > From: bin...@li...
> > [mailto:bin...@li...] On
> > Behalf Of Alex Black
> > Sent: Saturday, 30 June 2001 2:58 AM
> > To: binarycloud-dev
> > Subject: [binarycloud-dev] FW: GroupIT Engine
> >
> >
> > interwwesting
> >
> > --
> > alex black, ceo
> > en...@tu...
> >
> > the turing studio, inc.
> > http://www.turingstudio.com
> >
> > vox+510.666.0074
> > fax+510.666.0093
> >
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>

Re: [binarycloud-dev] Awwww man, facility, not policy!!!

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

> path separator), kills me.  Why?  Because I, in my
> world,
> use:
> 
> 	*.layout	for layout template files
> 	*.master	for master templates files
> 	*.mod		for modules

As we are evolving BC towards the more makefile-driven
r2, we decided to standardize the various file type
extensions:
Makefiles need standard extensions so as there
are standard rules that can do one thing for one type
of a file and a different thing for another type of a
file. That's why if you write your C application
you are stuck ending all your files with .c etc etc.

> At first, I thought this "dot" thing was kind of
> interesting when I started looking around.  I
> wondered
> if there was a refugee from the Xanadu project now
> working on BC...

The package/import notation and functionality is
mimicking the package/import of java/perl etc.
As you have guessed, this feature puts an additional
requirement for a single source code extension. 

The packaging feature become a necessity
as you move from small software projects to big ones.
Languages that were built from the begining for large
scale programming, like Java, had that feature from
birth. 
Languages like perl, in their original versions
allowed any extension and lacked the packaging
functionality. As the perl applications became deeper
and deeper the packages were introduced. To use the
packages you had to name your files *.pm . 
In some ways PHP is like perl in its infancy. Projects
like BC are trying to enable its use not only for
web-site-making but also for more heavy duty web
applications and in that sense are forced to make use
of some of these more "advanced" features. 
 
odysseas

> 
> OK, I'll conform to your policy, for now, so I can
> keep going.  But I won't shut up on this one.  This
> is a real bitch, not gentle observation.
> 
> _jef
>  


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

Re: [binarycloud-dev] Awwww man, facility, not policy!!!

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

> I don't get to first base.  Immediately, with the new gizmo
> as used in import() in the prepend, but also (evidently)
> in the parsing of th $bc_page hash, of substituting "/" for a dot
> (I suppose this is going to allow you to use the MS "\"
> path separator), kills me.  Why?  Because I, in my world,
> use:
>
> *.layout for layout template files
> *.master for master templates files
> *.mod for modules

ah, I did this for a number of reasons: I tried all the different extensions
in r1, and they ended up being annoying, not useful as I had oroginally
imagined.

Also, import works by taking package names, so you are talking about a path,
but it's better to think of import like:

binarycloud.core.Perm
which allows us to also do:

metabase.foo

and

pear.foo

for example.

> I am not going to justify myself (very much anyway),
> I just think that, BY INSPECTION, I know the "content"
> and/or the purpose of the file.  This is my policy.
> It avoids problems and confusion.  Now, you are
> forcing policy on me, you make me have _all_ my files
> end with ".php", WHEN THERE IS NO REASON TO.  These
> modules/layouts/templates are not in the DOCUMENT_ROOT
> where httpd _has_ to have known filename extensions.
> These files are down in the boiler room, conceptually,
> they have nothing, per se, to require a certain
> naming convention to operate properly.
>
> You have sinned, my son.

heh, but we need a way to differentiate between files that need to be
interpreted by xml2php from files that do not.

that means we must have a mechanism for doing that, which _at_the_moment_ is
by extension - and I don't see a really good way around that, short of
putting markers in files.

> Just to rub in a bit more salt, here is the conceptual
> "site", the "Hello World" site, and you have, in this
> package of files TWO files named example.php.  One
> is a master, the other is a layout.  You don't have
> to use much imagination to see the problems that
> could unnecessarily occur, a tarball, for example.
> Phooey.  Fiddlesticks.  Lordy.  Pox on ya.

But that's just my laziness, not a good counter example :)

also, yes, theoretically you could use

foo.master

and foo.layout
and

foo.mod
foo.lib
and
foo.foo

but that presents numerous other problems.
I _believe_ import will actually return a filename if it has a different
name than .php, after it looks for the .php... but I would have to look.

In any case it's not a big deal to do that, which would support most of what
you are talking about.

> At first, I thought this "dot" thing was kind of
> interesting when I started looking around.  I wondered
> if there was a refugee from the Xanadu project now
> working on BC...
>
> OK, I'll conform to your policy, for now, so I can
> keep going.  But I won't shut up on this one.  This
> is a real bitch, not gentle observation.

That import is very Java-like, which I prefer from the perspective of
structure.

Re: different extensions, I'm willing to entertain them but I prefer to use
directory structure rather than file extension wherever possible.

_but_ if I can come up with a good way to accomodate both ways of doing
things, I will.

_alex

RE: [binarycloud-dev] FW: GroupIT Engine

[Jimmy H. <ji...@ha...>]

Alex,

Will BC be as cool as GroupIT? I just saw their sample site thumbnails
and it looks nice (of course it's just 'looks') hehe

Come on alex I need BC! :)


Ohh btw you are not going to sell BC like GroupIT are you? I hope not
hehe
cheers

> -----Original Message-----
> From: bin...@li... 
> [mailto:bin...@li...] On 
> Behalf Of Alex Black
> Sent: Saturday, 30 June 2001 2:58 AM
> To: binarycloud-dev
> Subject: [binarycloud-dev] FW: GroupIT Engine
> 
> 
> interwwesting
> 
> --
> alex black, ceo
> en...@tu...
> 
> the turing studio, inc.
> http://www.turingstudio.com
> 
> vox+510.666.0074
> fax+510.666.0093
> 

[binarycloud-dev] Awwww man, facility, not policy!!!

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

Alex:

Shucks.

Here I sit down tonight to revise my modules to make them
run in the latest r2 with ubiquitous Makefiles.

Shucks.

I don't get to first base.  Immediately, with the new gizmo
as used in import() in the prepend, but also (evidently)
in the parsing of th $bc_page hash, of substituting "/" for a dot
(I suppose this is going to allow you to use the MS "\"
path separator), kills me.  Why?  Because I, in my world,
use:

	*.layout	for layout template files
	*.master	for master templates files
	*.mod		for modules

I am not going to justify myself (very much anyway),
I just think that, BY INSPECTION, I know the "content"
and/or the purpose of the file.  This is my policy.
It avoids problems and confusion.  Now, you are
forcing policy on me, you make me have _all_ my files
end with ".php", WHEN THERE IS NO REASON TO.  These
modules/layouts/templates are not in the DOCUMENT_ROOT
where httpd _has_ to have known filename extensions.
These files are down in the boiler room, conceptually,
they have nothing, per se, to require a certain
naming convention to operate properly.

You have sinned, my son.

Just to rub in a bit more salt, here is the conceptual
"site", the "Hello World" site, and you have, in this
package of files TWO files named example.php.  One
is a master, the other is a layout.  You don't have
to use much imagination to see the problems that
could unnecessarily occur, a tarball, for example.
Phooey.  Fiddlesticks.  Lordy.  Pox on ya.

At first, I thought this "dot" thing was kind of
interesting when I started looking around.  I wondered
if there was a refugee from the Xanadu project now
working on BC...

OK, I'll conform to your policy, for now, so I can
keep going.  But I won't shut up on this one.  This
is a real bitch, not gentle observation.

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

Re: [binarycloud-dev] Permissions?

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

> I need something that can handle:
> 1) Permission to view the page;

got it.

> 2) permission to view part of a page;

do you mean module?
we have permissions for entity operations, but not modules. that is
intentional because modules can both be aware of the permission context, and
if you use entitymanager, are governed by Entity Operations.

> 3) permission to view target items handled by a page;

I need a more detailed explanation of this.

> 4) of multiple types (files, directories, messages, etc)

perms only controls access to pages processed by php in htdocs - but does it
globally for that.

> 5) that can be assigned on the fly and re-assigned as needed without making
> the user get a PHD in how to use the system.

We'll most likely have an editor for it, and all the files are xml and
pretty simple.

> Something I've ben struggling with for a while now.

If you can describe the couple up there that I'm not clear on, I'll give you
a complete picture.


_alex




> -Ben 
> 
> On Friday 29 June 2001 17:43, you wrote:
>>> I have a rather large, complicated project, and am waiting for the
>>> permissions information for r2. Doesn't appear that this has been updated
>>> in the spec - What is the final goal for this stuff?
>> 
>> it's getting there, that's the secon major piece of core to be done.
>> 
>> I can tell you that unless you're doing something _really_ esoteric, the
>> infrastructure we'll have will ddo what you need :)
>> 
>> Can you give me an idea of some specific requirements that I can speak to?
>> 
>> _alex
>> 
>>> -Ben
>> 
>> --
>> alex black, ceo
>> en...@tu...
>> 
>> the turing studio, inc.
>> http://www.turingstudio.com
>> 
>> vox+510.666.0074
>> fax+510.666.0093
>> 
>> 
>> 
>> _______________________________________________
>> binarycloud-dev mailing list
>> bin...@li...
>> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] Permissions?

[Benjamin D. S. <be...@be...>]

I need something that can handle: 
	1) Permission to view the page; 
	2) permission to view part of a page; 
	3) permission to view target items handled by a page; 
	4) of multiple types (files, directories, messages, etc) 
	5) that can be assigned on the fly and re-assigned as needed without making 	
	the user get a PHD in how to use the system. 

Something I've ben struggling with for a while now. 

-Ben 

On Friday 29 June 2001 17:43, you wrote:
> > I have a rather large, complicated project, and am waiting for the
> > permissions information for r2. Doesn't appear that this has been updated
> > in the spec - What is the final goal for this stuff?
>
> it's getting there, that's the secon major piece of core to be done.
>
> I can tell you that unless you're doing something _really_ esoteric, the
> infrastructure we'll have will ddo what you need :)
>
> Can you give me an idea of some specific requirements that I can speak to?
>
> _alex
>
> > -Ben
>
> --
> alex black, ceo
> en...@tu...
>
> the turing studio, inc.
> http://www.turingstudio.com
>
> vox+510.666.0074
> fax+510.666.0093
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

Re: [binarycloud-dev] Permissions?

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

> I have a rather large, complicated project, and am waiting for the
> permissions information for r2. Doesn't appear that this has been updated in
> the spec - What is the final goal for this stuff?

it's getting there, that's the secon major piece of core to be done.

I can tell you that unless you're doing something _really_ esoteric, the
infrastructure we'll have will ddo what you need :)

Can you give me an idea of some specific requirements that I can speak to?

_alex


> -Ben 


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

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

vox+510.666.0074
fax+510.666.0093