binarycloud-dev — development list for binarycloud

Re: [binarycloud-dev] UIManager naming question

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

> If the UIManager is used to simply generate output for FORM elements,
> why not call this the FormManager?  Is this just too trivial to matter,
> or does the UIManager do more than this?
> 
> Jason

For a couple reasons:

    -there is (or will be) a "FormBuilder" - which does the actual assembly
of forms, and deals with doing validation using entity manager.

    -You can build extra-fancy custom UI components of your own that do cute
things like pop-up a calendar and place the selected date into a field, or
maybe construct a dependent list of pulldowns from two lists, etc. These can
be very useful when you're building "rich" applications instead of simple
forms.


_alex



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

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

vox+510.666.0074
fax+510.666.0093

[binarycloud-dev] UIManager naming question

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

If the UIManager is used to simply generate output for FORM elements,
why not call this the FormManager?  Is this just too trivial to matter,
or does the UIManager do more than this?


Jason

Re: He? (Re: [binarycloud-dev] Various)

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

> What is a "bare variable"?


$foo = array(
    moo => "boo",  <-- incorrect "bare" array key
    'boo' => 'foo' <-- correct quoted key
);

I had error reporting turned way down when I was building page (that's my
production config, for obvious reasons, and I always forget stuff like that.

Odysseas saw it, and mentioned it, so I cranked error reporting way up and
fixed everything it whined about.

:)

_a

>>> So, after reading the r2 "specification", this really
>>> seemed right.  So we are waiting.  I wish to compliment
>>> you on your very impressive concept and, so far, what
>>> is in the CVS that we are now playing with.  I suppose
>>> our only reservation is our worry that binarycloud
>>> reaches that "critical mass" where basic modules are
>>> going to be contributed, and "ported" from some of the
>>> other systems.  We are certainly going to be doing this,
>>> from Great Circle/Lat/Long/ZIP modules to maybe even
>>> a dynamic report generator for MySQL.  It is hoped
>>> that the module collection will allow, eventually,
>>> slapping together a basic intranet quickly.
>> 
>> cool.
>> 
>>> Just a couple of questions:
>>> 
>>> 1.  We notice that you use bare variables in the hashes.
>>> We used to, by accident, when we left quotes off.
>>> I think bare variables are legal in Perl, but
>>> the question is -- IS THIS ON PURPOSE?  Maybe
>>> 18 months ago I asked the PHP list if bare
>>> variables are "supported" since there was nothing
>>> in the manual to suggest that they were.  Rasmus
>>> replied that because of the mechanization of the
>>> symbol table, or some such, THEY WORK AS A SIDE
>>> EFFECT, but that "this behaviour is not guaranteed
>>> in the future".  Upshot, don't use bare variables
>>> if you don't want your code to blow up in 2003.
>> 
>> This is a result of me not synching CVS with my core repository. I am
>> waiting to do that when I have a make system that I think is pretty much
>> final.
>> 
>> I think it would be _really_ _really_ confusing for people to deal with a
>> moving structure re: the make system.
>> 
>> Re bare vars in hashes, no that's laziness that I fixed a while ago :)
>> 
>> I have copies of everything in CVS that use no bare vars for array keys, as
>> that is bad style :)
>> If you turn up error reporting high enough, it will tell you :)
>> 
>>> 2.  Why do you return true from the modules->Init()
>>> and modules->Output?  Is this just good, knee-jerk
>>> practice right now, or is there some kind of
>>> "recovery" mechanism anticipated, say, in the
>>> future when the returns will be tested.
>> 
>> No, knee-jerk.
>> It may (read: probably) go away, actually, because as yet I cannot think of
>> anything that would "govern" Init. I haven't put a great deal of thinking
>> into non-Page+Modules use of bc, which is why those returns are there...
>> i.e. I haven't decided how to have people use components of core like
>> auth/sess/etc, without using Page.
>> 
>>> 3. [Frivolous]  Do you want an email pointing out simple
>>> spelling errors/typos in content and comments?
>> 
>> Not yet, because 90% of them are probably gone.
>> After I release r2/make, yes.
>> 
>> I have done some major renaming + structural changes because of the make
>> system, that included applying proper r2 headers to all files.
>> 
>> If you have any typos in the core class method comments, send 'em :)
>> 
>>> So, we again wish to compliment you, and encourage you.
>>> It is an impressive piece of work.
>> 
>> Thank you, very much. It's good to hear and it is certainly encouraging.
>> 
>> The make system is opening up so many possibilties, it will be _very_
>> exciting to release it :)
>> 
>> I realize it has been a bit quietly, but I want to make sure that the next
>> pre release which contains make is as close to "final" as possible... so
>> people can start to use r2 for building actual applications.
>> 
>> ohhh, and you haven't seen import, have you? :)
>> 
>>> Regards,
>>> 
>>> --
>>> Justin Farnsworth - Technical Director
>>> Eye Integrated Communications
>>> 321 South Evans - Suite 203
>>> Greenville, NC 27858 | Tel: (252) 353-0722
>>> 
>> :)
>> 
>> _alex
>> 
>> 
>> _______________________________________________
>> 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

He? (Re: [binarycloud-dev] Various)

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

What is a "bare variable"? 

-Ben 

On Monday 18 June 2001 22:25, you wrote:
> > So, after reading the r2 "specification", this really
> > seemed right.  So we are waiting.  I wish to compliment
> > you on your very impressive concept and, so far, what
> > is in the CVS that we are now playing with.  I suppose
> > our only reservation is our worry that binarycloud
> > reaches that "critical mass" where basic modules are
> > going to be contributed, and "ported" from some of the
> > other systems.  We are certainly going to be doing this,
> > from Great Circle/Lat/Long/ZIP modules to maybe even
> > a dynamic report generator for MySQL.  It is hoped
> > that the module collection will allow, eventually,
> > slapping together a basic intranet quickly.
>
> cool.
>
> > Just a couple of questions:
> >
> > 1.  We notice that you use bare variables in the hashes.
> > We used to, by accident, when we left quotes off.
> > I think bare variables are legal in Perl, but
> > the question is -- IS THIS ON PURPOSE?  Maybe
> > 18 months ago I asked the PHP list if bare
> > variables are "supported" since there was nothing
> > in the manual to suggest that they were.  Rasmus
> > replied that because of the mechanization of the
> > symbol table, or some such, THEY WORK AS A SIDE
> > EFFECT, but that "this behaviour is not guaranteed
> > in the future".  Upshot, don't use bare variables
> > if you don't want your code to blow up in 2003.
>
> This is a result of me not synching CVS with my core repository. I am
> waiting to do that when I have a make system that I think is pretty much
> final.
>
> I think it would be _really_ _really_ confusing for people to deal with a
> moving structure re: the make system.
>
> Re bare vars in hashes, no that's laziness that I fixed a while ago :)
>
> I have copies of everything in CVS that use no bare vars for array keys, as
> that is bad style :)
> If you turn up error reporting high enough, it will tell you :)
>
> > 2.  Why do you return true from the modules->Init()
> > and modules->Output?  Is this just good, knee-jerk
> > practice right now, or is there some kind of
> > "recovery" mechanism anticipated, say, in the
> > future when the returns will be tested.
>
> No, knee-jerk.
> It may (read: probably) go away, actually, because as yet I cannot think of
> anything that would "govern" Init. I haven't put a great deal of thinking
> into non-Page+Modules use of bc, which is why those returns are there...
> i.e. I haven't decided how to have people use components of core like
> auth/sess/etc, without using Page.
>
> > 3. [Frivolous]  Do you want an email pointing out simple
> > spelling errors/typos in content and comments?
>
> Not yet, because 90% of them are probably gone.
> After I release r2/make, yes.
>
> I have done some major renaming + structural changes because of the make
> system, that included applying proper r2 headers to all files.
>
> If you have any typos in the core class method comments, send 'em :)
>
> > So, we again wish to compliment you, and encourage you.
> > It is an impressive piece of work.
>
> Thank you, very much. It's good to hear and it is certainly encouraging.
>
> The make system is opening up so many possibilties, it will be _very_
> exciting to release it :)
>
> I realize it has been a bit quietly, but I want to make sure that the next
> pre release which contains make is as close to "final" as possible... so
> people can start to use r2 for building actual applications.
>
> ohhh, and you haven't seen import, have you? :)
>
> > Regards,
> >
> > --
> > Justin Farnsworth - Technical Director
> > Eye Integrated Communications
> > 321 South Evans - Suite 203
> > Greenville, NC 27858 | Tel: (252) 353-0722
> >
> :)
>
> _alex
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

Re: [binarycloud-dev] A small question on a mystery...

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

> Alex:
> 
> Are you pulling our leg?  We notice that since PHP cannot use
> dots in variables that PHP converts all POST/GET var names,
> replacing the dot with an underscore.
> 
> In your demo of Hello World, you use a dot in a GET variable
> to switch the layout (.tmpl).  This, of course, gets converted
> to _tmpl, which you are testing for the switching.
> 
> Why do you do this?  Is there some higher meaning?  Are you
> just chuckling to yourself because you finally got someone
> to bite on this little insignificant thingy?

heheh, no.

It is "stylistically" significant, all url "messaging" to core will contain
.foo -> _foo

It's nice because you have a way of differentiating between those vars and
other just by the name. We'll have to get those thorough Request soon, but
for the moment they're global.

> I feel like I am writing Dear Abby.

hehe, oh shit I hope I don't start receiving letters about "what should I do
about my girlfriend? what should I do about my girlfriend?"

heh,

_alex


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

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

vox+510.666.0074
fax+510.666.0093

[binarycloud-dev] A small question on a mystery...

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

Alex:

Are you pulling our leg?  We notice that since PHP cannot use
dots in variables that PHP converts all POST/GET var names,
replacing the dot with an underscore.

In your demo of Hello World, you use a dot in a GET variable
to switch the layout (.tmpl).  This, of course, gets converted
to _tmpl, which you are testing for the switching.

Why do you do this?  Is there some higher meaning?  Are you
just chuckling to yourself because you finally got someone
to bite on this little insignificant thingy?

I feel like I am writing Dear Abby.

Regards,

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

Re: [binarycloud-dev] Uh, A Gadfly's Problem

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

> I don't wish to be a gadfly on the ass of progress, but I

heh, that's good :)

> would like to discuss my/our problem vis-a-vis using bc
> r2 in our not untypical small web development business.
> 
> As I have previously stated, I am impressed with the
> elegant qualities of bc r2, and have decided on these
> perceived merits to have our company "commit" to using
> bc in the future.  I have no real problem in waiting for
> the core completion, and I think there is a way to develop in the
> interim by using (as you did in Hello World) the artifice
> of putting "raw" PHP/HTML in the SomeModule->Init() and
> SomeModule->Output() methods.  (I will ask you about this
> later.)
> 
> But, I am in the midst of writing a justification position
> of going to bc for our partners/management, and I simply
> would like a best guess on your part as to when the Makefile
> system will be usuable "enough", when some of the Managers
> will be usuable "enough".  This is not meant to be pressure,
> but we would like to have a feeling for this, simply for
> our planning.

Makefile system is usable now, I'm sitting on it to make sure there isn't
anything that I don't like.

So, within ~1 week.

Managers: a little longer, I expect those to be fully functional in about a
month or so. Trying for less, but there you have it.

> I would like for you to comment on what you consider the
> best way to work in the interim.  From our study, it
> seems that to allow writing code today should allow
> easy "upgrading" as bc matures, would be the following, all
> of which assumes a typical dynamic site using PHP/MySQL:
> 
> FOR MODULES
> -----------
> 1. Write PHP code in the Module->Init() that gets the data
> from the database or whatever.

Yep.

> 2. Write HTML/PHP in the Module->Output() to display/do
> what the modules "purpose" is

Yep.

> 3. As Managers are released, rewrite, say, the Module->Init()
> to include the functionality of, say, Entity and
> Query.

Yep.

> 4. As Managers are released, rewrite, say, the Module->Output()
> to include the functionality of, say UI/Rule/Event.

Rule may well disappear.
Event will likely change and be a little more simple.
UI is used by the builders:
    ListBuilder
    FormBuilder
    etc.

You will probably not find it useful separate from them.


> This is how I see how to "start now" and preserve the layer
> and abstraction, and allow us to get "Les Artistes" (what I
> call the design/Mac people) up to speed on using this wonderful
> touchstone/Holy Grail of separating-layout-from-content.

So far so good, le les artistes do their designs + html, and decide how much
you you would like to use XSLT in your projects. From there, either take
that html and php-ify it, or xslt-ifyit :)

> Is this approach what you would do?  I would like your
> comments.

Yes, pretty much.

I have one other comment: when you design your schemas, keep in mind that
you are trying to build entities: data structures which can be nested.

So, for example:

"user"
    user_name (string, no more than 40 chars, no special chars allowed)

    password (encrypted string, no more than 40 chars, no special chars
allowed)

    address (fkey/entity reference)
        street_address
        phone_number
        foo

    email   (string, must match a regex:
"^([a-z0-9_]|\\-|\\.)+@(([a-z0-9_]|\\-)+\\.)+[a-z]{2,3}\$"
    no more than 255 chars)

etc.

that will allow you to define entities fairly quickly once the system is
ready, and from them you'll be able to build queries automatically.

You might want to store a set of english "labels" for each of those fields,
too:

User name
Password
Address
    Street Address
    Phone Number
    Foo
Email

As entities include labels for the fields (so FormBuilder can make forms for
your automatically :)

> One other more mundane question.  How would you (maybe
> this answer is already implicit) organize your directory
> structure under the BC_PATH for, say, a website.  I
> am thinking:
> 
> FOR TEMPLATES
> 1.  Under BC_PATH_TMPL/masters/ create a directory site_name.
> 2.  In the XML or bc_page structure, make the paths
> ==> "html/masters/site_name/template_to_use"

That is one way to do it. But only if you are running separate sites off the
same installation, which might have other problems (configuration, etc)

I like to keep mine just in masters, I've never had more than 5.

But that's all arbitrary, so if you like you can store them in

html/foo/bar/moo/bar/aliens/ate/my/lunch/and/it/had/chocolate/milk/too/

> FOR MODULE LAYOUT
> 1.  Under BC_PATH_MOD/html/layouts/ create a directory site_name
> 2.  In the XML or bc_page structure, make the paths
> ==> "html/layouts/site_name/layout_to_use"

Ditto above.

> FOR MODULES THAT ARE GENERAL, Reusable
> 1.  Under BC_PATH_MOD establish a set of directories that
> reflect "category of module" such as
> ./forms
> ./locators
> ./tables
> ./pagers
> ./gizmos
> 2.  In the XML or bc_page structure, make the paths
> ==> "forms/magic_form.php" or
> ==> "tables/super_table1.php"

No.

You're much better off structuring and perceiving modules as complete
applications:

knowledge_base
forum
etc.

instead of:
    my tables, my forms, etc.

because tables and forms will soon be extremely easy to generate.

Sometimes it also makes sense to cut out a "process" and make it a module:
"checkout" etc.

> FOR MODULES THAT ARE SITE-SPECIFIC, one-offs
> 1.  Under BC_PATH_MOD create a directory site_name
> 2.  In the XML or bc_page structure, make the paths
> ==> "site_name/whatever_specific_mod.php"

That's an interesting point.
I have never considered doing it that way, but come to think of it that's
probably a good, simple way to deal with it.

> It is likely you will comment "whatever organization that
> suits you".  I just wish to make certain that CVS updates
> will not mangle this system in the future.

Everything you have mentioned will not break.

> As an observation, one of the most appealing features of bc
> for me is this perception that such organization can
> be made, and the repository "method" for modules is
> intuitive and natural.  You may think that this great
> administration advantage is self-evident, but you
> should toot your horn more about this concept as it
> is something of value that transcends the code itself.

Thanks.

Actually all that is going to get even more "lax" in the source tree,
because the makefile will take care of actually organizing the code for you.
(heheh)

So the next release of r2 will have fewer directories in user/, because
there's no reason to make an artificial separation in source. That will make
packaging and installing modules _really_ easy. (think all the files you
need in once place, instead of 5 places, but with none of the disadvantages
of having similar files distributed throughout a tree)

I have tried to structure everything so it's easy to find, etc, but I wanted
to specifically avoid enforcing "the way I do things" on people. Couldn't do
that 100%, but it seems pretty reasonable so far :)

_alex


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] I know its not a php tutorial list...

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

$this->varname is a class variable reference.

think of

$varname, but attached to the containing class, and only usable within that
context, sort of like variables in functions.

$this=>varname isn't valid. This is:

$foo = array(
    'moo' => "boo",
    'foo' => "hoo"
);

Those are array keys, so you can reference:

$foo['moo'] and get "boo"


_alex


> I would love to know what the $this->varname and $this=>varname syntax
> means. It seems it has to do something with arrays or global variables.
> Anyone want to take a stab at this for me?
> 
> Alby
> al...@th...
> 
> 
> _______________________________________________
> 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

[binarycloud-dev] Uh, A Gadfly's Problem

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

Alex:

I don't wish to be a gadfly on the ass of progress, but I
would like to discuss my/our problem vis-a-vis using bc
r2 in our not untypical small web development business.

As I have previously stated, I am impressed with the
elegant qualities of bc r2, and have decided on these
perceived merits to have our company "commit" to using
bc in the future.  I have no real problem in waiting for
the core completion, and I think there is a way to develop in the
interim by using (as you did in Hello World) the artifice
of putting "raw" PHP/HTML in the SomeModule->Init() and
SomeModule->Output() methods.  (I will ask you about this
later.)

But, I am in the midst of writing a justification position
of going to bc for our partners/management, and I simply
would like a best guess on your part as to when the Makefile
system will be usuable "enough", when some of the Managers
will be usuable "enough".  This is not meant to be pressure,
but we would like to have a feeling for this, simply for
our planning.

I would like for you to comment on what you consider the
best way to work in the interim.  From our study, it
seems that to allow writing code today should allow
easy "upgrading" as bc matures, would be the following, all
of which assumes a typical dynamic site using PHP/MySQL:

FOR MODULES
-----------
1. Write PHP code in the Module->Init() that gets the data
	from the database or whatever.
2. Write HTML/PHP in the Module->Output() to display/do
	what the modules "purpose" is
3. As Managers are released, rewrite, say, the Module->Init()
	to include the functionality of, say, Entity and
	Query.
4. As Managers are released, rewrite, say, the Module->Output()
	to include the functionality of, say UI/Rule/Event.

This is how I see how to "start now" and preserve the layer
and abstraction, and allow us to get "Les Artistes" (what I
call the design/Mac people) up to speed on using this wonderful
touchstone/Holy Grail of separating-layout-from-content.

Is this approach what you would do?  I would like your
comments.

One other more mundane question.  How would you (maybe
this answer is already implicit) organize your directory
structure under the BC_PATH for, say, a website.  I
am thinking:

FOR TEMPLATES
1.  Under BC_PATH_TMPL/masters/ create a directory site_name.
2.  In the XML or bc_page structure, make the paths
	==> "html/masters/site_name/template_to_use"

FOR MODULE LAYOUT
1.  Under BC_PATH_MOD/html/layouts/ create a directory site_name
2.  In the XML or bc_page structure, make the paths
	==> "html/layouts/site_name/layout_to_use"

FOR MODULES THAT ARE GENERAL, Reusable
1.  Under BC_PATH_MOD establish a set of directories that
	reflect "category of module" such as
	./forms
	./locators
	./tables
	./pagers
	./gizmos
2.  In the XML or bc_page structure, make the paths
	==> "forms/magic_form.php" or
	==> "tables/super_table1.php"

FOR MODULES THAT ARE SITE-SPECIFIC, one-offs
1.  Under BC_PATH_MOD create a directory site_name
2.  In the XML or bc_page structure, make the paths
	==> "site_name/whatever_specific_mod.php"

It is likely you will comment "whatever organization that
suits you".  I just wish to make certain that CVS updates
will not mangle this system in the future.

As an observation, one of the most appealing features of bc
for me is this perception that such organization can
be made, and the repository "method" for modules is
intuitive and natural.  You may think that this great
administration advantage is self-evident, but you
should toot your horn more about this concept as it
is something of value that transcends the code itself.

Regards,

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

[binarycloud-dev] I know its not a php tutorial list...

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

I would love to know what the $this->varname and $this=>varname syntax
means. It seems it has to do something with arrays or global variables.
Anyone want to take a stab at this for me?

Alby
al...@th...

Re: [binarycloud-dev] Various

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

> So, after reading the r2 "specification", this really
> seemed right.  So we are waiting.  I wish to compliment
> you on your very impressive concept and, so far, what
> is in the CVS that we are now playing with.  I suppose
> our only reservation is our worry that binarycloud
> reaches that "critical mass" where basic modules are
> going to be contributed, and "ported" from some of the
> other systems.  We are certainly going to be doing this,
> from Great Circle/Lat/Long/ZIP modules to maybe even
> a dynamic report generator for MySQL.  It is hoped
> that the module collection will allow, eventually,
> slapping together a basic intranet quickly.

cool.

> Just a couple of questions:
>
> 1.  We notice that you use bare variables in the hashes.
> We used to, by accident, when we left quotes off.
> I think bare variables are legal in Perl, but
> the question is -- IS THIS ON PURPOSE?  Maybe
> 18 months ago I asked the PHP list if bare
> variables are "supported" since there was nothing
> in the manual to suggest that they were.  Rasmus
> replied that because of the mechanization of the
> symbol table, or some such, THEY WORK AS A SIDE
> EFFECT, but that "this behaviour is not guaranteed
> in the future".  Upshot, don't use bare variables
> if you don't want your code to blow up in 2003.

This is a result of me not synching CVS with my core repository. I am
waiting to do that when I have a make system that I think is pretty much
final.

I think it would be _really_ _really_ confusing for people to deal with a
moving structure re: the make system.

Re bare vars in hashes, no that's laziness that I fixed a while ago :)

I have copies of everything in CVS that use no bare vars for array keys, as
that is bad style :)
If you turn up error reporting high enough, it will tell you :)

> 2.  Why do you return true from the modules->Init()
> and modules->Output?  Is this just good, knee-jerk
> practice right now, or is there some kind of
> "recovery" mechanism anticipated, say, in the
> future when the returns will be tested.

No, knee-jerk.
It may (read: probably) go away, actually, because as yet I cannot think of
anything that would "govern" Init. I haven't put a great deal of thinking
into non-Page+Modules use of bc, which is why those returns are there...
i.e. I haven't decided how to have people use components of core like
auth/sess/etc, without using Page.

> 3. [Frivolous]  Do you want an email pointing out simple
> spelling errors/typos in content and comments?

Not yet, because 90% of them are probably gone.
After I release r2/make, yes.

I have done some major renaming + structural changes because of the make
system, that included applying proper r2 headers to all files.

If you have any typos in the core class method comments, send 'em :)

> So, we again wish to compliment you, and encourage you.
> It is an impressive piece of work.

Thank you, very much. It's good to hear and it is certainly encouraging.

The make system is opening up so many possibilties, it will be _very_
exciting to release it :)

I realize it has been a bit quietly, but I want to make sure that the next
pre release which contains make is as close to "final" as possible... so
people can start to use r2 for building actual applications.

ohhh, and you haven't seen import, have you? :)

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

:)

_alex

[binarycloud-dev] Various

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

Alex:

This is just a potpourri of comments and questions.

First, it may be interesting for you that we have been
in a kind of festering turmoil as to what tools/system/API
to turn to for our web development.  We have looked to
some extent at most everything springing up in the open
source community.  All during this time it was always
tempting to attempt to roll our own.  We simply have
to get some order in our attempt to "Lego-ize" our sites
as we are continually reinventing the wheel and looking
for "that piece of code" that was somewhere, barely
remembering.

So, after reading the r2 "specification", this really
seemed right.  So we are waiting.  I wish to compliment
you on your very impressive concept and, so far, what
is in the CVS that we are now playing with.  I suppose
our only reservation is our worry that binarycloud
reaches that "critical mass" where basic modules are
going to be contributed, and "ported" from some of the
other systems.  We are certainly going to be doing this,
from Great Circle/Lat/Long/ZIP modules to maybe even
a dynamic report generator for MySQL.  It is hoped
that the module collection will allow, eventually,
slapping together a basic intranet quickly.

Just a couple of questions:

1.  We notice that you use bare variables in the hashes.
	We used to, by accident, when we left quotes off.
	I think bare variables are legal in Perl, but
	the question is -- IS THIS ON PURPOSE?  Maybe
	18 months ago I asked the PHP list if bare
	variables are "supported" since there was nothing
	in the manual to suggest that they were.  Rasmus
	replied that because of the mechanization of the
	symbol table, or some such, THEY WORK AS A SIDE
	EFFECT, but that "this behaviour is not guaranteed
	in the future".  Upshot, don't use bare variables
	if you don't want your code to blow up in 2003.

2.  Why do you return true from the modules->Init()
	and modules->Output?  Is this just good, knee-jerk
	practice right now, or is there some kind of
	"recovery" mechanism anticipated, say, in the
	future when the returns will be tested.

3. [Frivolous]  Do you want an email pointing out simple
	spelling errors/typos in content and comments?

So, we again wish to compliment you, and encourage you.
It is an impressive piece of work.

Regards,

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

Re: [binarycloud-dev] LGPL

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

> I wasn't suggesting that for binarycloud, just airing my views in public
> :-)  Some things should be free for all - base applications, operating
> systems etc.  I mean that the things that run on top of them - forums,
> shopping carts, code editors, shouldn't have to be free for business use -
> which seems to be the accepted view.

Shouldn't necessarily be free, but than I consider those kinds of
applications as great candidates for free stuff. "Not free" as far as I am
concerned are installation specific requirements for security, etc. Standard
applications with little modification should be available.

> It is very hard to draw that line, but I hope you understand what I'm on
> about :-)

It is, and I don't think it should be drawn. If someone is selling a forum,
that someone else needs and they want to buy it, great!

:)

_a

Re: [binarycloud-dev] LGPL

[Peter B. <re...@f2...>]

At 01:28 PM 6/14/01 -0700, you wrote:
> > make the product free for personal use, and cost $$ for business use,
> > become more accepted on the internet.  That way I could fund my way through
> > University by selling <promote> sendcard <http://www.sendcard.f2s.com>
> > </promote> :-)
> > </soapbox>
>
>I thought about doing something along those lines. But _even_with_ all the
>forking and etc, I prefer linux and other os s/w to most proprietary
>products. OS code is usually user-driven, inherently flexible, and
>thoroughly tested. yes of course there is shit out there, but in general I
>find os stuff to be better quality.

I wasn't suggesting that for binarycloud, just airing my views in public 
:-)  Some things should be free for all - base applications, operating 
systems etc.  I mean that the things that run on top of them - forums, 
shopping carts, code editors, shouldn't have to be free for business use - 
which seems to be the accepted view.

It is very hard to draw that line, but I hope you understand what I'm on 
about :-)
Peter.


--oOo--
Narrow Gauge on the web - photos, directory and forums!
http://www.narrow-gauge.co.uk
--oOo--
Peter's web page - Scottish narrow gauge in 009
http://members.aol.com/reywob/
--oOo--

[binarycloud-dev] anyone out there use bbedit?

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

well, if you do, a gift:


(*
This script properly formats xml (really)
*)

tell application "BBEdit 6.1"
    activate
    
    format mode hierarchical
    replace "([^>])
([    ]+)<" using "\\1<" searching in text 1 of text window 1 options
{search mode:grep, starting at top:true, wrap around:false}
    
    replace ">\\r([\\t]+)(\\w)([^<]+)</" using ">\\2\\3</" searching in text
1 of text window 1 options {search mode:grep, starting at top:true, wrap
around:false}
    replace ">\\r([\\s]+)(#+)</" using ">\\2</" searching in text 1 of text
window 1 options {search mode:grep, starting at top:true, wrap around:false}
    replace "}}} -->
<" using "}}} -->

<" searching in text 1 of text window 1 options {search mode:literal,
starting at top:true, wrap around:false}
    
end tell


that applescript formats xml perfectly :) it was a pain in the ass to
construct :) enjoy...

_a


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] LGPL

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

> Another option is (L)GPL'ing the development/bleeding-edge version, and having
> a BSD-licensed version lag behind. MySQL does (or at least used to do)
> something like this, although with completely opposite goals. This encourages
> contribution more than a defacto dual license, especially as long as
> binarycloud's feature list is rapidly growing.

I can't see that working, i.e. people aren't interested in r1 if r2 is out
and working :)

I would prefer to settle on one, clean license that encourages and enforces
contribution in the event of redistribution, and (yes) makes credit
mandatory.

_a


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

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

vox+510.666.0074
fax+510.666.0093

[binarycloud-dev] bpl (ha-ha)

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

yeah, why not!

binarycloud public license
----------------------------------------------------------------------------

Use of this software is subject to the terms of this license. By using this
software you accept the terms of this license and agree to be bound by them.

Redistribution and/or use in source and binary/encoded forms, with or
without modification, are permitted provided that the following conditions
are met:

-Redistributions of source code must retain this license, this list of
conditions and the following disclaimer.

-Redistributions in binary/encoded form must include this license, this list
of conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.

-Redistributions in binary/encoded form must include a complete copy of
machine-readable source code.

-Redistributions in any form must include credit for the binarycloud
consortium in the documentation and/or other materials provided with the
distribution.

-Redistributions in source or binary/encoded form of modified versions must
be available to any party at no charge under the terms of this license.

-Redistributions in source or binary/encoded form of modified versions must
contain clear documentation of changes.

-Neither the name "binarycloud", nor the names of its contributors may be
used to endorse or promote products derived from this software without
specific prior written permission from all members of the binarycloud
consortium.


disclaimer:
----------------------------------------------------------------------------
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
----------------------------------------------------------------------------

agh!!!!!!

_a

Re: [binarycloud-dev] LGPL

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

> Alex,
> 
> Well, neither LGPL nor BSD force re-contribution if another product isn't
> distributed.

Correct. That is absolutely fine with me. You build some strange shit for
nasa that they want to keep, fine. Distribution is what's important.

They want to publish it, fine, but they have to contribute the changes they
have made to the base system back to the project.

I like that.

> The issue we found with LGPL is that an OS vendor (to remain nameless for a
> little while yet) was not comfortable bundling iODBC until we changed the
> license.  If you examine points 5 and 6 of the LGPL, they appear to enforce
> the same viral contribution clause, and have some contradictory language as
> far as what constitutes a 'derived work'.

This is true, to a certain extent, the language is a little muddled.

> Basically, a case could be made that everyone has to be LGPL (or GPL) with
> code they write that uses bc in any way.

"However, linking a "work that uses the Library" with the Library creates an
executable that is a derivative of the Library (because it contains portions
of the Library), rather than a "work that uses the library". The executable
is therefore covered by this License. Section 6 states terms for
distribution of such executables."

I think this is what you are referring to.

section 6 states:
"As an exception to the Sections above, you may also combine or link a "work
that uses the Library" with the Library to produce a work containing
portions of the Library, and distribute that work under terms of your
choice, provided that the terms permit modification of the work for the
customer's own use and reverse engineering for debugging such
modifications."

Ouch, flaw in the license.

This effectively makes commercial application vendors give away source code.
It _doesn't_ make them license it under lgpl or gpl, but the above is enough
to make most commercial people a little nervous :)

I like this:
"You must give prominent notice with each copy of the work that the Library
is used in it and that the Library and its use are covered by this License.
You must supply a copy of this License. If the work during execution
displays copyright notices, you must include the copyright notice for the
Library among them, as well as a reference directing the user to the copy of
this License."

> Now this is not so bad, but you may be restricting distribution of
> commercial products built with bc.

The distinction between "core" and "user" code is very important (and more
rigidly enforced) in r2.

Commercial distribution of binarycloud core is acceptable so long as proper
credit is given.

Commercial distribution of code in user/ is up to the copyright holder of
that code. (I.e. if you build modules within binarycloud, you retain the
copyright, and are welcome to use whatever license you desire.)

To be included in the php core of the binarycloud distro, code must be
released under the LGPL by the copyright holder, and accept that credit will
be given to the consortium (of which they would be a member)

> Also, while a lot of companies are starting to use open source, there is
> still a big aversion to GPL, and LGPL cannot be separated from that in
> lawyers' minds due to the ambiguity in points 5 and 6.
> 
> Just my .02 - I really am not adverse to LGPL, but think it's muddy water.

It's definitely more complex that "this is 100% completely free, have a nice
day" - because everyone involved needs to retain copyright and proper use of
the code they contribute. This is especially important for commercial
projects.

hey, who's up for a "BPL" (binarycloud public license) ha-ha!

:)

_a

Re: [binarycloud-dev] LGPL

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

> This is the one thing that worries me about the accepted open source
> licenses: they make it too easy not to have to contribute improvements, and
> give you the ability to fork.

this is why I prefer GPLish licenses. I am not interested in giving away the
code for all to use/fork/claim/etc as they please. I _am_ interested in
having a robust set of freely-usable code that carries some obigations for
use:
    -credit
    -contribution of changes if they are distributed.

> It is the forking part that I really don't like, and I believe it is
> harming the community rather than helping it.  Look at Linux or PHP-Nuke
> for an example.  If everyone had worked together on either of those
> products rather than developing their own version, they would be much
> further on.

yep.

> For this reason I have never released my code under an open source
> license.  In fact my code isn't licensed at all, which is worse, but I
> haven't found a license I like and/or understand yet :-)

I have considered making a simple license which is about as long as BSD, but
has the contribution requirement.

> By all means, let people modify the code to suit their uses, but make them
> distribute the modifications as patches or modules, rather than forking and
> forming a new distribution called asciicloud, replicating all that already
> exists in binarycloud and just changing a few small areas... and diluting
> the programmers over two very similar projects.

Exactly. Especially given that I have invested actual $ in its development.

> <soapbox>
> Recently I have come across a few PHP projects where the owner has changed
> the license from GPL or similar, because people have been using the script
> in ways he never intended it to be (e.g. as a module in PHP-Nuke, with the
> credit removed).  I do believe in open source, but I also do not like
> licenses which say that everything must be free, which the GPL does.
> 
> People are not all programming for nothing (as thankfully Alex seems to be
> doing with Binarycloud) - I personally would like to see licenses which

I'm not either. I have a business to run. I think OS code is the way to fly:
if I make this system people will use and benefit from it, and I'll get free
stuff (and so will everyone else). I think that's cool.

At the same time I am not interested in having "asciicloud" :) happen, nor
am I amenable to having binarycloud distributed as a commercial product
without credit.

> make the product free for personal use, and cost $$ for business use,
> become more accepted on the internet.  That way I could fund my way through
> University by selling <promote> sendcard <http://www.sendcard.f2s.com>
> </promote> :-)
> </soapbox>

I thought about doing something along those lines. But _even_with_ all the
forking and etc, I prefer linux and other os s/w to most proprietary
products. OS code is usually user-driven, inherently flexible, and
thoroughly tested. yes of course there is shit out there, but in general I
find os stuff to be better quality.




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

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

vox+510.666.0074
fax+510.666.0093

RE: [binarycloud-dev] LGPL

[John D. <jo...@we...>]

On Thu, 14 Jun 2001, Peter Bowyer wrote:

> At 02:40 PM 6/14/01 -0400, you wrote:
<<snip>>
> 
> It is the forking part that I really don't like, and I believe it is 
> harming the community rather than helping it.  Look at Linux or PHP-Nuke 
> for an example.  If everyone had worked together on either of those 
> products rather than developing their own version, they would be much 
> further on.
> 

I don't think you can paint with such a broad brush. gcc/egcs is a case where
forking resulted in a better end product. emacs/xemacs is a famous case where
the two projects continued on their seperate paths, but both have loyal user
bases, so the community was still well-served.

> For this reason I have never released my code under an open source 
> license.  In fact my code isn't licensed at all, which is worse, but I 
> haven't found a license I like and/or understand yet :-)
> 

I'm not sure anyone fully understands the licenses ;)

<<snip>>
> 
> People are not all programming for nothing (as thankfully Alex seems to be 
> doing with Binarycloud) - I personally would like to see licenses which 
> make the product free for personal use, and cost $$ for business use, 
> become more accepted on the internet.  That way I could fund my way through 
> University by selling <promote> sendcard <http://www.sendcard.f2s.com> 
> </promote> :-)
> </soapbox>
> 

Another option is (L)GPL'ing the development/bleeding-edge version, and having
a BSD-licensed version lag behind. MySQL does (or at least used to do)
something like this, although with completely opposite goals. This encourages
contribution more than a defacto dual license, especially as long as
binarycloud's feature list is rapidly growing. 

-- 

John Donagher

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD

RE: [binarycloud-dev] LGPL

[Peter B. <re...@f2...>]

At 02:40 PM 6/14/01 -0400, you wrote:
>Well, neither LGPL nor BSD force re-contribution if another product isn't=
=20
>distributed.

This is the one thing that worries me about the accepted open source=20
licenses: they make it too easy not to have to contribute improvements, and=
=20
give you the ability to fork.

It is the forking part that I really don't like, and I believe it is=20
harming the community rather than helping it.  Look at Linux or PHP-Nuke=20
for an example.  If everyone had worked together on either of those=20
products rather than developing their own version, they would be much=20
further on.

For this reason I have never released my code under an open source=20
license.  In fact my code isn't licensed at all, which is worse, but I=20
haven't found a license I like and/or understand yet :-)

By all means, let people modify the code to suit their uses, but make them=
=20
distribute the modifications as patches or modules, rather than forking and=
=20
forming a new distribution called asciicloud, replicating all that already=
=20
exists in binarycloud and just changing a few small areas... and diluting=20
the programmers over two very similar projects.

<soapbox>
Recently I have come across a few PHP projects where the owner has changed=
=20
the license from GPL or similar, because people have been using the script=
=20
in ways he never intended it to be (e.g. as a module in PHP-Nuke, with the=
=20
credit removed).  I do believe in open source, but I also do not like=20
licenses which say that everything must be free, which the GPL does.

People are not all programming for nothing (as thankfully Alex seems to be=
=20
doing with Binarycloud) - I personally would like to see licenses which=20
make the product free for personal use, and cost $$ for business use,=20
become more accepted on the internet.  That way I could fund my way through=
=20
University by selling <promote> sendcard <http://www.sendcard.f2s.com>=20
</promote> :-)
</soapbox>

Just my =A300.02
Peter.


-oOo-
Maple Design - web design, hosting, domain names
http://www.mapledesign.co.uk
-oOo-

RE: [binarycloud-dev] LGPL

[Andrew <an...@sa...>]

Alex,

Well, neither LGPL nor BSD force re-contribution if another product isn't
distributed.

The issue we found with LGPL is that an OS vendor (to remain nameless for a
little while yet) was not comfortable bundling iODBC until we changed the
license.  If you examine points 5 and 6 of the LGPL, they appear to enforce
the same viral contribution clause, and have some contradictory language as
far as what constitutes a 'derived work'.

Basically, a case could be made that everyone has to be LGPL (or GPL) with
code they write that uses bc in any way.
Now this is not so bad, but you may be restricting distribution of
commercial products built with bc.

Also, while a lot of companies are starting to use open source, there is
still a big aversion to GPL, and LGPL cannot be separated from that in
lawyers' minds due to the ambiguity in points 5 and 6.

Just my .02 - I really am not adverse to LGPL, but think it's muddy water.

Best regards,
Andrew

> -----Original Message-----
> From: bin...@li...
> [mailto:bin...@li...]On Behalf Of Alex
> Black
> Sent: Thursday, June 14, 2001 2:09 PM
> To: binarycloud-dev
> Subject: Re: [binarycloud-dev] LGPL
>
>
> > Alex,
> >
> > We've run into problems with LGPL adoption with one of our
> products (iODBC).
> > This got so bad with larger companies eyeing it suspiciously
> (because its
> > legal language is vague as far as how it differs from the GPL,
> and it could
> > impose the same 'viral' licensing) that we finally released
> iODBC under a
> > BSD license as well.  Not that the situations are identical by
> any means,
> > but you may run into problems in the long run with bc adoption in large
> > companies with legal departments that find LGPL unacceptable.
>
> hi andrew, as always good point :)
>
> I personally dislike BSD because it does not enforce
> "re-contribution" which
> I think is a fundamentally good thing to force. BSD basically says
> "whatever, this is free"
>
> Can you give me a specific example of problems brought to your attention
> with LGPL?
>
> _a
>
>
> --
> 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] LGPL

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

> Alex,
> 
> We've run into problems with LGPL adoption with one of our products (iODBC).
> This got so bad with larger companies eyeing it suspiciously (because its
> legal language is vague as far as how it differs from the GPL, and it could
> impose the same 'viral' licensing) that we finally released iODBC under a
> BSD license as well.  Not that the situations are identical by any means,
> but you may run into problems in the long run with bc adoption in large
> companies with legal departments that find LGPL unacceptable.

hi andrew, as always good point :)

I personally dislike BSD because it does not enforce "re-contribution" which
I think is a fundamentally good thing to force. BSD basically says
"whatever, this is free"

Can you give me a specific example of problems brought to your attention
with LGPL?

_a


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

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

vox+510.666.0074
fax+510.666.0093

Re: [binarycloud-dev] LGPL

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

BTW - I make extensive use of the PHPLIB libraries, and they are LGPL as 
well. 

-Ben 

On Wednesday 13 June 2001 23:27, you wrote:
> > Seems the best way to go. You want to make the application development
> > environment (BC) as free as possible, but you don't want to make
>
> developers
>
> > release the applications developed herewith released under the same
> > freedom/restrictions.
>
> Correct. (given that I am in that business, I agree! :)
>
> > If this were straight-up GPL, I would be unable to use it. On the other
>
> hand,
>
> > as LGPL, I could use it, develop the applications my customers need, and
> > still be likely to contribute to the part that benefits you.  (the BC
> > environment itself)
>
> Yep. I encourage people to think of how they can generalize their
> components, so we can include them in the distro. The more the better, as
> far as I am concerned.
>
> > IMHO, GPL-type licensing applies best to infrastructure - the specific
> > application of that infrastructure to solve a specific problem is
>
> generally
>
> > best a more proprietary license.
>
> Depends on the software, but _usually_ I agree with that statement. I think
> it is reasonable to classify binarycloud as infrastructure software (that
> and I have that on my company website :)
>
> _alex
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev

-- 
"Life is short. Live it!"

Re: [binarycloud-dev] LGPL

[Robert W. <rob...@fr...>]

Sounds like a good idea to me.

On Thursday 14 June 2001  5:15 am, alex black wisely wrote:
> hi all,
>
> I'm leaning heavily towards releasing all r2 code under the LGPL:
>
> http://www.gnu.org/copyleft/lesser.html
>
> does anyone have opinions on that?
>
> note some stuff:
>     -the r1 license header will be much smaller:
> * -License    LGPL     (http://www.gnu.org/copyleft/lesser.html)
>
>     -all contributors of _complete_ components retain copyright on those
> components. (i.e. you don't get copyright for fixing a bug, :)
>     -all authors who are responsible for 20% or more of a document will be
> credited
>     -all individual authors retain copyright on work
>     -all corporations retain copyright on work.
>
> obviously that assumes that the work is published under the LGPL under the
> auspices of the binarycloud consortium.
>
> -------
>
> The above has a number of ramifications:
>     -modifications to binarycloud core, and some user stuff, if
> distributed, must be free (per lgpl)
>     -BUT, unlike r1, no permission from turing is required for use, and all
> of the code may be integrated into commercial products _so_long_ as proper
> credit is given. the credit will be to the binarycloud consortium, not
> specific organizations (to avoid the whole
> original-bsd-license-credit-nightmare-list problem.)
>
> this is a significant change, but I think it's appropriate given the
> evolution of the sysem.
>
> please, any and all comments/flames/rants/etc...
>
> _alex
>
>
>
>
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> http://lists.sourceforge.net/lists/listinfo/binarycloud-dev