Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alex B. <en...@tu...> - 2001-09-25 23:39:34
|
yeah,
I think:
-SML as the standard, we'll of course allow any custom extensions that
have attribute support.
for all pure-xml files, I prefer XML by far.
-a
> Hi Manuel, Alex,
>=20
>>> I'm kinda unsure. I like both and both is descriptive as well as
>>> standardized ;-) But, in the bcp we use the "simple" format
>>> and maybe we should keep this convetion throughout.
>>>=20
>>> What are you're thoughts on this?
>>=20
>> I think you are right, because XML is only really extensible if
>> you can later add tags to values to extend the meaning of those
>> values. Since you can=B4t have tags in tag attributes, it is better
>> to use SML.
>=20
> Yes this is a good point. And it would be a mess to rewrite the entire
> xml->php behaviour at a later point.
>=20
> I.e if we want to extend the name tag (just an example, makes not very mu=
ch
> sense in this case):
>=20
> <bc:module>
> <name>
> <internal>BcHelloWorld</internal>
> <descriptive>Hello World</descriptive>
> </name>
> ..
> </bc:module>
>=20
> Ok, the readbility lacks, especially for very short tags (i.e. <bc:img
> id=3D"23" />). But I think it's worth the effort. At a later point we can
> support parameters if users want to use it, or they can implement their o=
wn
> compiler that handles them)
>=20
>> BTW, MetaL XML files are fully SML.
> That's exactly what brought up this thought here :-)
>=20
> Andi
>=20
>=20
>=20
> _______________________________________________
> binarycloud-dev mailing list
> bin...@li...
> https://lists.sourceforge.net/lists/listinfo/binarycloud-dev
>=20
|
|
From: Andreas A. <a.a...@th...> - 2001-09-25 23:32:24
|
Hi Alex, >In this case I like attributes, but I see andi and jason's point. There is >also (of course) the "it could work right now" thing. > >So, let's use the SML syntax for the moment (I'll update that >file, wherever it is in CVS) Ok, agreed. I've changed an checked in the "compilertest.html" and a XMLUtils based working ModuleCompiler (don't look at the code, it's not clean) but it works :-) Andi |
|
From: Alex B. <en...@tu...> - 2001-09-25 23:27:58
|
>> Wouldn't this be better accomplished with a user-definable field-type with an >> associated I/O class..having a tag called "encrypt" seems too simplistic to >> really provide any meaningful encryption service.. > > For example: we'll have systeic heh, that is not a word. somehow "systemic" became "systeic" _a |
|
From: Andreas A. <a.a...@th...> - 2001-09-25 23:27:43
|
Hi Manuel, Alex,
>>I'm kinda unsure. I like both and both is descriptive as well as
>>standardized ;-) But, in the bcp we use the "simple" format
>>and maybe we should keep this convetion throughout.
>>
>>What are you're thoughts on this?
>
>I think you are right, because XML is only really extensible if
>you can later add tags to values to extend the meaning of those
>values. Since you can´t have tags in tag attributes, it is better
>to use SML.
Yes this is a good point. And it would be a mess to rewrite the entire
xml->php behaviour at a later point.
I.e if we want to extend the name tag (just an example, makes not very much
sense in this case):
<bc:module>
<name>
<internal>BcHelloWorld</internal>
<descriptive>Hello World</descriptive>
</name>
..
</bc:module>
Ok, the readbility lacks, especially for very short tags (i.e. <bc:img
id="23" />). But I think it's worth the effort. At a later point we can
support parameters if users want to use it, or they can implement their own
compiler that handles them)
>BTW, MetaL XML files are fully SML.
That's exactly what brought up this thought here :-)
Andi
|
|
From: Alex B. <en...@tu...> - 2001-09-25 23:19:21
|
> Wouldn't this be better accomplished with a user-definable field-type with an > associated I/O class..having a tag called "encrypt" seems too simplistic to > really provide any meaningful encryption service.. For example: we'll have systeic control over encryption settings, but I think it's safe to assume that a developer would want to use the same key length and settings for all the fields (as it would be a nightmare to maintain a key per field, etc) in the entity definition, encryption is as simple as "encrypt" ... elsewhere we'll have very fine control over what exactly happens as a result. ... We will have an I/O class if I read manuel's previous message correctly, and that will load a configuration file. probably called conf/Encryption.php or something :) does that make sense or did I miss your point? _alex |
|
From: Andreas A. <a.a...@th...> - 2001-09-25 23:14:00
|
Hi, > btw, the encryption support is done by adding > another file to the distro, > not patching, so you only include the file if you need it. Yeah, and that can be enabled using <mcrypt>true</mcrypt> within the bcp <database> section :-) Andi |
|
From: Andreas A. <a.a...@th...> - 2001-09-25 23:11:54
|
Hi, hehe, oh I have a old courier modem somewhere, I think i'll connect it just to hear the groovy sound again ;-) Andi >Whoa, what happened? Reminds me of the old: >+++ATH0ÉÉh¹ßÝzùsSX§,X¬µ¸§j¼?-??ýNO CARRIER > > >> Markus >KrummenackerÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÛSv«ÉÉh¹ßÝzùsSX§,X¬µ >¸§j¼?-??ýׯþX¬¶Ïì¢êÜyú+?ïçzØm¶?ÿÿùb²Ûÿ²?«qçè®ÿ?ë-+-³ùb²Ø§~?ÛSv«ÉÉh¹ßÝ >n)Ú¯'%¢ç]zùX§X¬µ¸§j¼uëåËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ >ÏåËbú?n)Ú¯'%¢ç] |
|
From: John D. <jo...@we...> - 2001-09-25 22:40:20
|
On Tue, 25 Sep 2001, Alex Black wrote: > added .. <encrypt> to field defs. > Wouldn't this be better accomplished with a user-definable field-type with an associated I/O class..having a tag called "encrypt" seems too simplistic to really provide any meaningful encryption service.. -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD |
|
From: Alex B. <en...@tu...> - 2001-09-25 22:09:18
|
> Question: These should not be in the user/ dir anyway now, correct? > These are not in the user/default/ dir. > If so, you should remove them from the CVS repository. Well, the make system doesn't do multi-site make yet, and I'm loth to break the installation in CVS in thge expectation that multi-site make will work at some time in the future. So, for the moment they should stay, until you check in your makefile changes. best, _alex > > > Alex Black wrote: >> To make things simple, when you check out, cd into user, and do this >> >> rm -rf cache/ >> rm -rf conf/ >> rm -rf db/ >> rm -rf htdocs/ >> rm -rf lang/ >> rm -rf lib/ >> rm -rf mod/ >> rm -rf roles/ >> rm -rf tmpl/ > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-09-25 21:24:10
|
> Alex Black writes: >> added entity:desc, and <encrypt> to field defs. >> >> any other comments? >> >> best, >> >> -alex >> >> <?php > $entity => array( > 'name' => 'furbees', > 'desc' => > 'This is an example entity used for development.', > 'manager' => > 'FurbeesManager', > 'database' => array( > 'name' => > ...etc... > > alex, in the future, is it possible for you to paste this as text with > standard unix LFs ? line wrapping is just shot with these pastes from > a Mac... In CVS, the files are fine... unfortunately Entourage (the client I use) doesn't know about anything but mac linebreaks. _a |
|
From: Alex B. <en...@tu...> - 2001-09-25 21:22:39
|
ok, that sounds great. btw, the encryption support is done by adding another file to the distro, not patching, so you only include the file if you need it. _a > Hello, > >>> Would this be suitable for allowing one to have fields automatically be >>> encrypted in the database? >>> This seems like more of a Metabase question, but I have no experience >>> with Metabase. >> >> It's a mix. But it certainly belongs in the entity def. I'll add it. >> >>> At first thought, I'd say use mcrypt to encrypt/decrypt the data >>> automatically to/from the database if the encrypt tag is TRUE in the >>> entity definition. >> >> That's what happens in r1 > > BTW, I am starting to implement LOB support to Metabase. Passing data to LOBs > will use input stream objects. These objects will be of classes derived from a > Metabase input stream class. In the derived classes you can supply data with > functions that may do all sorts of things link for instance filtering data > (encrypting, compressing, etc...). > > I want to make these input stream objects also work with non-LOB fields to > promote further reuse. I want to provide basic input stream classes for > passing data defined statically or from files. I think that is the place for > you to provide further classes to do other types of other filtering without > patching Metabase. > > Regards, > Manuel Lemos > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Jason H. <jc...@ey...> - 2001-09-25 20:40:24
|
V2hvYSwgd2hhdCBoYXBwZW5lZD8gIFJlbWluZHMgbWUgb2YgdGhlIG9sZDoNCisrK0FUSDDJ yWi53916+XNTWKcsWKy1uKdqvD8tPz/9Tk8gQ0FSUklFUg0KDQoNCj4gTWFya3VzIEtydW1t ZW5hY2tlcv//////////////////////////////////////////////21N2q8nJaLnf3Xr5 c1NYpyxYrLW4p2q8Py0/P/3Xr/5YrLbP7KLq3Hn6Kz/v53rYbbY////5YrLb/7I/q3Hn6K4H /z/rfy0rLbP5YrLYp34/21N2q8nJaLnf3Q0K |
|
From: Jason H. <jc...@ey...> - 2001-09-25 20:38:01
|
DQpXaG9hLi4gaGFkIHRvIGFzay4gIFdoYXQgaGFwcGVuZWQgaGVyZT8gIFJlbWluZHMgbWUg b2YgdGhlIG9sZA0KKysrQVRI21N2q8nJaLnf3Xr5c1NYpyxYrLW4p2q8Py1OTyBDQVJSSUVS DQoNCj5LcnVtbWVuYWNrZXL//////////////////////////////////////////////9tT dqvJyWi53916+XNTWKcsWKy1uKdqvD8tPz/916/+WKy2z+yi6tx5+is/7+d62G22P///+WKy 2/+yP6tx5+iuB/8/638tKy2z+WKy2Kd+P9tTdqvJyWi5390NCg== |
|
From: Jason H. <jc...@ey...> - 2001-09-25 20:26:33
|
Question: These should not be in the user/ dir anyway now, correct? These are not in the user/default/ dir. If so, you should remove them from the CVS repository. Alex Black wrote: > To make things simple, when you check out, cd into user, and do this > > rm -rf cache/ > rm -rf conf/ > rm -rf db/ > rm -rf htdocs/ > rm -rf lang/ > rm -rf lib/ > rm -rf mod/ > rm -rf roles/ > rm -rf tmpl/ |
|
From: Manuel L. <man...@uo...> - 2001-09-25 20:23:20
|
Hello, >> Would this be suitable for allowing one to have fields automatically be >> encrypted in the database? >> This seems like more of a Metabase question, but I have no experience >> with Metabase. > >It's a mix. But it certainly belongs in the entity def. I'll add it. > >> At first thought, I'd say use mcrypt to encrypt/decrypt the data >> automatically to/from the database if the encrypt tag is TRUE in the >> entity definition. > >That's what happens in r1 BTW, I am starting to implement LOB support to Metabase. Passing data to LOBs will use input stream objects. These objects will be of classes derived from a Metabase input stream class. In the derived classes you can supply data with functions that may do all sorts of things link for instance filtering data (encrypting, compressing, etc...). I want to make these input stream objects also work with non-LOB fields to promote further reuse. I want to provide basic input stream classes for passing data defined statically or from files. I think that is the place for you to provide further classes to do other types of other filtering without patching Metabase. Regards, Manuel Lemos |
|
From: kr <kr...@pa...> - 2001-09-25 20:18:16
|
QWxleCBCbGFjayB3cml0ZXM6DQogPiBhZGRlZCBlbnRpdHk6ZGVzYywgYW5kIDxlbmNyeXB0 PiB0byBmaWVsZCBkZWZzLg0KID4gDQogPiBhbnkgb3RoZXIgY29tbWVudHM/DQogPiANCiA+ IGJlc3QsDQogPiANCiA+IC1hbGV4DQogPiANCiA+IDw/cGhwDSRlbnRpdHkgPT4gYXJyYXko DSAgICAnbmFtZScgPT4gJ2Z1cmJlZXMnLA0gICAgJ2Rlc2MnID0+DQonVGhpcyBpcyBhbiBl eGFtcGxlIGVudGl0eSB1c2VkIGZvciBkZXZlbG9wbWVudC4nLA0gICAgJ21hbmFnZXInID0+ DQonRnVyYmVlc01hbmFnZXInLA0gICAgJ2RhdGFiYXNlJyA9PiBhcnJheSgNICAgICAgICAn bmFtZScgPT4NCi4uLmV0Yy4uLg0KDQphbGV4LCBpbiB0aGUgZnV0dXJlLCBpcyBpdCBwb3Nz aWJsZSBmb3IgeW91IHRvIHBhc3RlIHRoaXMgYXMgdGV4dCB3aXRoDQpzdGFuZGFyZCB1bml4 IExGcyA/ICBsaW5lIHdyYXBwaW5nIGlzIGp1c3Qgc2hvdCB3aXRoIHRoZXNlIHBhc3RlcyBm cm9tDQphIE1hYy4uLg0KDQp0aGFua3MuDQoNCi0tIA0KUmVnYXJkcywNCk1hcmt1cyBLcnVt bWVuYWNrZXI= |
|
From: Alex B. <en...@tu...> - 2001-09-25 20:02:25
|
added entity:desc, and <encrypt> to field defs. any other comments? best, -alex |
|
From: Alex B. <en...@tu...> - 2001-09-25 19:32:27
|
hi all,
I just did a ground-up sync from my core repository to sourceforge.. please
do an update of your local cvs, and have a look around:
Jason:
I have added two directories to user/ for your benefit:
user/bcdev/ (this is an _exact_ copy of the former user/ tree, now
as a 'site'
user/default/ (a subset of the files in user/ before, that I think
are necessary for each 'site make') we'll refine that list later.
I suggest you use user/bcdev/ to get 'site' make working.
To make things simple, when you check out, cd into user, and do this
rm -rf cache/
rm -rf conf/
rm -rf db/
rm -rf htdocs/
rm -rf lang/
rm -rf lib/
rm -rf mod/
rm -rf roles/
rm -rf tmpl/
that should leave you with:
Makefile
bcdev
default
... so that way you can do something like
find ./ -type d -maxdepth 1 | grep -ve 'default' | grep -ve 'CVS'
to get a list of the sites you should make.
one request:
please, please, _please_ do not check in until you are absolutely certain
your make system works well.
once you get to that point, I'll check in, sync, and remove all the old
contents of user/
best,
-alex
|
|
From: Alex B. <en...@tu...> - 2001-09-25 18:39:40
|
hmm... In this case I like attributes, but I see andi and jason's point. There is also (of course) the "it could work right now" thing. So, let's use the SML syntax for the moment (I'll update that file, wherever it is in CVS) _a > Hi All, > > I just realized that we're using simplified XML (SML) throughout the system > (except for the bc:module, bc:href, etc. tags). What do you think of keeping > it simple also with the bc:*-tags? > > -- the attributes way -- > <bc:module id="moo" name="HelloWorld" package="hello_world"> > <cache expires="30" use_uri="true" var="$moo"/> > <params> > <param_name>value</param_name> > <another_param_name>another_value</another_param_name> > </params> > </bc:module> > <bc:href id="href" href="/archive/mp3/any_document.mp3" usedocroot="true" /> > > -- the sml way -- > <bc:module> > <id>moo</id> > <name>HelloWorld</name> > <package>some.package</package> > <cache> > <expires>30</expires> > <use_uri>true</use_uri> > <var>$moo</var> > </cache> > <params> > <param_name>value</param_name> > <another_param_name>another_value</another_param_name> > </params> > </bc:module> > > <bc:href> > <id>href</id> > <href>/archive/mp3/any_document.mp3</href> > <usedocroot>true</usedocroot> > </bc:href> > > I'm kinda unsure. I like both and both is descriptive as well as > standardized ;-) But, in the bcp we use the "simple" format and maybe we > should keep this convetion throughout. > > What are you're thoughts on this? > > :andi > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > https://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Alex B. <en...@tu...> - 2001-09-25 18:37:18
|
> > ok, this is a shot in the dark but the idea just hit me while tossing in > my sleep. > > RE: entity definitions > > <encrypt>true</encrypt> Sort of, and thank you for mentioning that because I did miss it. However, it won't be on the entity level, it will be on the field level. > Would this be suitable for allowing one to have fields automatically be > encrypted in the database? > This seems like more of a Metabase question, but I have no experience > with Metabase. It's a mix. But it certainly belongs in the entity def. I'll add it. > At first thought, I'd say use mcrypt to encrypt/decrypt the data > automatically to/from the database if the encrypt tag is TRUE in the > entity definition. That's what happens in r1 _a |
|
From: Alex B. <en...@tu...> - 2001-09-25 18:35:59
|
> So, if the tables are not listed, then does Metabase create a table based on > the entity definition? I'm not clear on how the entity field to database > field mapping happens automagically. We will be able to generate metabase schema definitions from entity definitions, but I don't (can't) force a 1:1 correspondence with entity field names and table column names. The short answer is that if you build something relatively simple with binarycloud you will almost certainly have a 1:1 field correspondence, but if you're building something more complex you'll need more entities to provide you with 'views' of your data. _alex |
|
From: Manuel L. <man...@uo...> - 2001-09-25 16:50:55
|
Hello, >I just realized that we're using simplified XML (SML) throughout the sys= tem >(except for the bc:module, bc:href, etc. tags). What do you think of kee= ping >it simple also with the bc:*-tags? > >-- the attributes way -- ><bc:module id=3D"moo" name=3D"HelloWorld" package=3D"hello_world"> > <cache expires=3D"30" use_uri=3D"true" var=3D"$moo"/> > <params> > <param_name>value</param_name> > <another_param_name>another_value</another_param_name> > </params> ></bc:module> ><bc:href id=3D"href" href=3D"/archive/mp3/any_document.mp3" usedocroot=3D= "true" /> > >-- the sml way -- ><bc:module> > <id>moo</id> > <name>HelloWorld</name> > <package>some.package</package> > <cache> > <expires>30</expires> > <use_uri>true</use_uri> > <var>$moo</var> > </cache> > <params> > <param_name>value</param_name> > <another_param_name>another_value</another_param_name> > </params> ></bc:module> > ><bc:href> > <id>href</id> > <href>/archive/mp3/any_document.mp3</href> > <usedocroot>true</usedocroot> ></bc:href> > >I'm kinda unsure. I like both and both is descriptive as well as >standardized ;-) But, in the bcp we use the "simple" format and maybe we >should keep this convetion throughout. > >What are you're thoughts on this? I think you are right, because XML is only really extensible if you can l= ater add tags to values to extend the meaning of those values. Since you = can=B4t have tags in tag attributes, it is better to use SML. That is the reason why Metabase XML format is also in SML. I realized the= need to make it SML when I added support to specify external variables w= ith tag values. That was right before I made first Metabase public releas= e. I am glad I did it. BTW, MetaL XML files are fully SML. I have forbidden non-SML constructs i= n the XML parser, just in case somebody (I) forgets. Regards, Manuel Lemos |
|
From: Andreas A. <a.a...@th...> - 2001-09-25 14:52:49
|
Hi All,
I just realized that we're using simplified XML (SML) throughout the system
(except for the bc:module, bc:href, etc. tags). What do you think of keeping
it simple also with the bc:*-tags?
-- the attributes way --
<bc:module id="moo" name="HelloWorld" package="hello_world">
<cache expires="30" use_uri="true" var="$moo"/>
<params>
<param_name>value</param_name>
<another_param_name>another_value</another_param_name>
</params>
</bc:module>
<bc:href id="href" href="/archive/mp3/any_document.mp3" usedocroot="true" />
-- the sml way --
<bc:module>
<id>moo</id>
<name>HelloWorld</name>
<package>some.package</package>
<cache>
<expires>30</expires>
<use_uri>true</use_uri>
<var>$moo</var>
</cache>
<params>
<param_name>value</param_name>
<another_param_name>another_value</another_param_name>
</params>
</bc:module>
<bc:href>
<id>href</id>
<href>/archive/mp3/any_document.mp3</href>
<usedocroot>true</usedocroot>
</bc:href>
I'm kinda unsure. I like both and both is descriptive as well as
standardized ;-) But, in the bcp we use the "simple" format and maybe we
should keep this convetion throughout.
What are you're thoughts on this?
:andi
|
|
From: jason <ja...@gr...> - 2001-09-25 07:23:12
|
ok, this is a shot in the dark but the idea just hit me while tossing in my sleep. RE: entity definitions <encrypt>true</encrypt> Would this be suitable for allowing one to have fields automatically be encrypted in the database? This seems like more of a Metabase question, but I have no experience with Metabase. At first thought, I'd say use mcrypt to encrypt/decrypt the data automatically to/from the database if the encrypt tag is TRUE in the entity definition. jason |
|
From: Gerry K. <ge...@mc...> - 2001-09-25 02:47:18
|
>> Overall, looks good, but just wondering why the declaration of fields >> is not nested within <database> and <table>. > > Because entity fields do not directly correspond with table > definitions. So, for example, you can completely forego the > entity:table section and just use the entity path to database field > mappings below. > > _a > So, if the tables are not listed, then does Metabase create a table based on the entity definition? I'm not clear on how the entity field to database field mapping happens automagically. Gerry -- IT Specialist | "Do not repay anyone evil for evil. If your enemy MCC | is hungry, feed him; if he is thirsty, give him Bangladesh | a drink. Do not be overcome by evil, | but overcome evil with good." - Bible ----------------------------------------- This email was sent using SquirrelMail. "Webmail for nuts!" http://squirrelmail.org/ |
5 messages has been excluded from this view by a project administrator.
