From: Nico G. <sc...@ac...> - 2001-05-19 20:19:34
|
hi, i've been following the mailinglist threads for a few months now, and i must say it has gone up exponentially :) there's quite some action on the road ahead, with the rc2 api taking form... hopefully the code will start coming soon...=20 in the meantime, i was wondering how you guys would compare binarycloud to other webapp frameworks such as horde, zope; cms systems a la phpgroupware and groupit or even weblogs like phpnuke... i will start coding a web community site soon (for a youth movement), with a lot of dynamic content such as photographs, bio's, shortstories, communication between members..=20 another thing i will want to do is delegate the content, so i will need some sort of cms system behind it, atleast for some area's of the site, depending on the member and her/his role in the movement. i think binarycloud (especially r2) looks very promising indeed, but don't you think the modules all by hand using the bc framework (or horde for that matter) will take alot more time and effort than starting out from a readymade cms system such as groupit? thanks for your thoughts... --nicolas -- nico galoppo - tremelo/leuven, belgium - erasmus/socrates student in grenoble, france - 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19 --------------------------------------------------------------- [bash]:~$ man woman nico at crossbar dot net No manual entry for woman debian linux :: vim powered |
From: Alex B. <en...@tu...> - 2001-05-19 21:03:16
|
> i've been following the mailinglist threads for a few months now, and i > must say it has gone up exponentially :) there's quite some action > on the road ahead, with the rc2 api taking form... hopefully the code > will start coming soon... > > in the meantime, i was wondering how you guys would compare binarycloud > to other webapp frameworks such as horde, zope; cms systems a la > phpgroupware and groupit or even weblogs like phpnuke... zope: mature used an annoying custom markup language (DTML I think it's called) uses its own database engine (?) it's OS, but if just feels proprietary. horde: I was not aware that a 'framework' existed, it does. but is seems empty? so, no idea. cms: binarycloud is not a cms. we are actually going to publish an extremely groovy xml-based cms for binarycloud in the future, but the system itself is not a cms. re: phpgroupware, I offered to share components with them, but I looked at the apps and they were full of echos for html, which is never a good sign :) no production experience with this. seems 'flat' i.e. a phplib competitor with a bit of structure added. overly oriented toward 'their' apps. phpnuke: headless monster. it grows really quickly, and some of the tools are useful, but it isn't really for "deep" application development. sort of like phplib if they had made it into a big collection of apps instead of just publishing the core libs. I should mention another tool, which though it is not mature, but has a couple good ideas: SiteManager. hyper-OO, they abstract html which I dislike, but they package modules nicely. XML Configuration too. but we do all that in r2 :) uh, so if I can huff-and-puff for a moment, I really haven't seen anyone even trying something as deep as r2 with php. that wasn't really true of r1, i.e. it had tools that existed elsewhere in different code - but r2 is entirely unique. the concepts and the code that will come out for this release will allow you to speed the development of your projects by a factor of 5. > i will start coding a web community site soon (for a youth movement), > with a lot of dynamic content such as photographs, bio's, shortstories, > communication between members.. cool. > another thing i will want to do is delegate the content, so i will need > some sort of cms system behind it, atleast for some area's of the site, > depending on the member and her/his role in the movement. Once we get a functioning r2 install, we're going to start in on a cms immediately, would you like to participate in its development? It will have a number of groovy features: -document version tracking -multi-language versions of the same document -an inline rich (read visual html) editor which works with IE5.5+ -everything will be xslt -we might get around to building a caching module for ripping documents ...this would probably be generalized, though - so you can flag a page as "cached" in the page def xml, and the system will automatically create a repository for cached markup and check that first. I think pear has a caching class, so we might just be able to plug it in! > i think binarycloud (especially r2) looks very promising indeed, but > don't you think the modules all by hand using the bc framework (or horde > for that matter) will take alot more time and effort than starting out > from a readymade cms system such as groupit? This is a point, but what we're trying to do is actually much more integrated with the system than "just a cms" we're going to build a generalized entity editor, that will edit any defined logical structure in the system. around that, we're going to wrap an artificial hierarchy-creator/browser, and we'll call the hierarchy browser plus the generalized entity editor "a cms". but the reality is that you'll just as easily be able to edit roles and users are you are able to edit articles. this all comes from the idea of entities, and the entitymanager. I think the most appropriate way to "wrap" other projects is to convert them to modules. The r2 module method spec is still a moving target, I just wrote some code today that breaks the published docs. But with the first r2 init/core release, it will be final. that means you can (fairly easily) wrap lightweight applications, as long as they don't try to start a session. however, part of the point of a system like r2 is to achieve complete integration within the system - so all these other tools like entityManager, rulemanager, eventmanager, etc won't be used by the code, and you won't gain the advantages that come with that. also, with the stuff we're doing, it will almost be easier to re-build a simple app than to port it in. the new formbuilder will only spit xml out, so we'll run that through a global xsl - that means you can write one xsl for 90% of the forms on your site. one document. for example, a forum: -define an entity: post -another: thread -another entity: forum immediately, you can get a list of posts and a list of forums without writing any more code. so far, you've spent 20 minutes writing 2 xml documents. then you spend another ~30 minutes creating modules which call the lister and form builder - which use global templates if you like, and 'bing' you have forums. now, granted, you could spend a couple days doing that if you wanted deluxe-o layouts, etc but overall the system will allow you to build applications at ridiculous speed. hope that clarifies a little for you :) > [bash]:~$ man woman > No manual entry for woman but that would take away all the fun! -alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Nico G. <sc...@ac...> - 2001-05-19 23:08:09
|
--* Alex Black (Sat, May 19, 2001 at 02:02:21PM -0700) *-- > uh, so if I can huff-and-puff for a moment, I really haven't seen anyon= e > even trying something as deep as r2 with php.=20 > the concepts and the code that will come out for this release will allo= w you > to speed the development of your projects by a factor of 5. ok, i was afraid you were going to say that ;) actually, i'm very interesting in getting involved with binarycloud, especially because you seem to be very groovy stuff with xml/xslt, although i don't fully understand how it all fits together yet, especially the 'entity' concept. > It will have a number of groovy features: > -document version tracking > -multi-language versions of the same document > -an inline rich (read visual html) editor which works with IE5.5+ Now this is something very cool that I've tried out at binarycloud.com/bc_edit... too bad it's only supported bye IE5.5+ > -everything will be xslt never done it, but i usually get convinced into using this kinda stuff quite easily :) > -we might get around to building a caching module for ripping docum= ents > ...this would probably be generalized, though - so you can flag a page = as > "cached" in the page def xml, and the system will automatically create = a > repository for cached markup and check that first. >=20 > I think pear has a caching class, so we might just be able to plug it i= n! i know pear has this, i think it was written by ulf wendel and that he's got extensive docs online on his website, but all in german (argh!). consequence: i don't even understand the concept of a 'caching module'. anyone care to explain??=20 > This is a point, but what we're trying to do is actually much more > integrated with the system than "just a cms" true. all that i'm afraid of is that 'implementing' a cms with this groovy state-of-the-art framework could be more timeconsuming and 'banging-your-head-against-the-wall' than just trying to use something that's been built allready. true, it takes the fun out of it, and limits the extensibility of your system...=20 > also, with the stuff we're doing, it will almost be easier to re-build = a > simple app than to port it in. the new formbuilder will only spit xml o= ut, > so we'll run that through a global xsl - that means you can write one x= sl > for 90% of the forms on your site. one document. >=20 > for example, a forum: > -define an entity: post > -another: thread > -another entity: forum now, this i don't get. maybe i should take a look at your 'complex example' post. should i take the 'r2 path release' and untar the 'complex example' in that tree?? --nicolas -- nico galoppo - tremelo/leuven, belgium - erasmus/socrates student in grenoble, france - 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19 --------------------------------------------------------------- [bash]:~$ man woman nico at crossbar dot net No manual entry for woman debian linux :: vim powered |
From: Alex B. <en...@tu...> - 2001-05-19 23:27:14
|
> ok, i was afraid you were going to say that ;) actually, i'm very > interesting in getting involved with binarycloud, especially because you > seem to be very groovy stuff with xml/xslt, although i don't fully > understand how it all fits together yet, especially the 'entity' > concept. This will be the subject of many posts, and detailed docs. > Now this is something very cool that I've tried out at > binarycloud.com/bc_edit... too bad it's only supported bye IE5.5+ yeah... ns is falling... > never done it, but i usually get convinced into using this kinda stuff > quite easily :) heh :) > i know pear has this, i think it was written by ulf wendel and that he's > got extensive docs online on his website, but all in german (argh!). > consequence: i don't even understand the concept of a 'caching module'. > anyone care to explain?? ok, say I have this nice page, which has 5 modules. each of these modules pulls content out of the database, and formats it with xslt. for a page that is 'static' i.e. you're just getting content from the database that doesn't rely on the userid or any session specific stuff.. it makes sense to take the html output of that page render, and put it in a file on the webserver. so next time a request comes in for that page, the cacher just pulls it out of the filesystem and serves it instead of going through: query xml xslt >> This is a point, but what we're trying to do is actually much more >> integrated with the system than "just a cms" > > true. all that i'm afraid of is that 'implementing' a cms with this > groovy state-of-the-art framework could be more timeconsuming and > 'banging-your-head-against-the-wall' than just trying to use something > that's been built allready. true, it takes the fun out of it, and limits > the extensibility of your system... You're welcome to do a quick conversion of another cms into binarycloud modules. :) But in this case, it makes sense to do it properly. > now, this i don't get. maybe i should take a look at your 'complex > example' post. should i take the 'r2 path release' and untar the > 'complex example' in that tree?? oh, "complex example" is a quick xslt tutorial/show n' tell. when I get the time I'll post a doc about entities. -a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Nico G. <sc...@ac...> - 2001-05-19 23:31:25
|
--* Alex Black (Sat, May 19, 2001 at 04:27:02PM -0700) *-- > oh, "complex example" is a quick xslt tutorial/show n' tell. >=20 > when I get the time I'll post a doc about entities. >=20 I took a quick look at the 'SmartForm Builder' at phpSiteManager you were talking about, and if the term 'entity' over there means the same to you, i think i get the picture... --nico -- nico galoppo - tremelo/leuven, belgium - erasmus/socrates student in grenoble, france - 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19 --------------------------------------------------------------- [bash]:~$ man woman nico at crossbar dot net No manual entry for woman debian linux :: vim powered |
From: Alex B. <en...@tu...> - 2001-05-19 23:59:10
|
> I took a quick look at the 'SmartForm Builder' at phpSiteManager you > were talking about, and if the term 'entity' over there means the same > to you, i think i get the picture... it doesn't :) I believe 'sm entities' are sort of form elements. imagine a bc entitiy like a database schema, but xml, in a hierarchy, and with a lot more meta information. -alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: jason <ja...@gr...> - 2001-05-20 02:54:39
|
if i am understanding this right, i think this is beautiful. it is strangely familiar concept i've played with, but nothing has ever taken off in code. alex, i wish you all the best and look forward to r2. you seem to have a great scheme of things in mind very well. i hope to help out when the time comes.. Nico Galoppo wrote: > > also, with the stuff we're doing, it will almost be easier to re-build a > > simple app than to port it in. the new formbuilder will only spit xml out, > > so we'll run that through a global xsl - that means you can write one xsl > > for 90% of the forms on your site. one document. > > > > for example, a forum: > > -define an entity: post > > -another: thread > > -another entity: forum > now, this i don't get. maybe i should take a look at your 'complex > example' post. should i take the 'r2 path release' and untar the > 'complex example' in that tree?? |
From: alex b. <en...@tu...> - 2001-05-20 05:13:58
|
> if i am understanding this right, i think this is beautiful. it is > strangely familiar concept i've played with, but nothing has ever taken > off in code. alex, i wish you all the best and look forward to r2. you > seem to have a great scheme of things in mind very well. i hope to help > out when the time comes.. there's much to do. I'm trying to get a releasable r2 core available as soon as possible, the manager and builder classes will follow soon after. r2 will be capable of handling new core components and "plugins" white elegantly, so we can build some fairly groovy things (caching not least among them) toil, toil, boil and bubble! :) _alex > > Nico Galoppo wrote: > > > also, with the stuff we're doing, it will almost be easier to re-build a > > > simple app than to port it in. the new formbuilder will only spit xml out, > > > so we'll run that through a global xsl - that means you can write one xsl > > > for 90% of the forms on your site. one document. > > > > > > for example, a forum: > > > -define an entity: post > > > -another: thread > > > -another entity: forum > > > now, this i don't get. maybe i should take a look at your 'complex > > example' post. should i take the 'r2 path release' and untar the > > 'complex example' in that tree?? > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
From: Peter B. <re...@f2...> - 2001-05-20 07:10:28
|
At 04:27 PM 5/19/01 -0700, you wrote: > > Now this is something very cool that I've tried out at > > binarycloud.com/bc_edit... too bad it's only supported bye IE5.5+ > >yeah... >ns is falling... Hopefully when Opera finish their DOM they'll support the W3C version of the above, as shown in the second link you provided us on the subject. Otherwise I'll have to use IE just for editing my website :-)) >for a page that is 'static' i.e. you're just getting content from the >database that doesn't rely on the userid or any session specific stuff.. But you could still start a session, couldn't you by calling all the init functions? Also, say the only difference between a logged in user and the logged out was an extra menu, couldn't you cache both? I guess I'm after a Smarty kind of template engine that'll process the XML/XSLT and then build in PHP queries/includes for the changing data... which would reduce the load caused by using XSLT. but then would probably get rid of the advantages :-) I guess this will by why the cache is best suited to a cms tool, where you don't have many logins (so those pages can be generated dynamically) and your content isn't changing very often. >it makes sense to take the html output of that page render, and put it in a >file on the webserver. > >so next time a request comes in for that page, the cacher just pulls it out >of the filesystem and serves it instead of going through: > query > xml > xslt Yup. Which will save ~ 0.0999 s off compile time? 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-- |
From: alex b. <en...@tu...> - 2001-05-20 18:09:45
|
> But you could still start a session, couldn't you by calling all the init > functions? Also, say the only difference between a logged in user and the Yes, I think the cache would be a plugin to the page class, not init. > logged out was an extra menu, couldn't you cache both? I guess I'm after a > Smarty kind of template engine that'll process the XML/XSLT and then build > in PHP queries/includes for the changing data... which would reduce the > load caused by using XSLT. but then would probably get rid of the > advantages :-) I don't quite get the above. splain me :) oh no, wait, got it. yes actually someone has done you one better, they have made an xslt -> c++ compiler, but the code doesn't work with sablot, we'll need to wait for php 4.1 to be able to use it. but I am not averse to thinking of ways to increase xslt's speed. but I can't sacrifice _any_ of its capabilities. > I guess this will by why the cache is best suited to a cms tool, where you > don't have many logins (so those pages can be generated dynamically) and > your content isn't changing very often. Correct-o > Yup. Which will save ~ 0.0999 s off compile time? Actually, probably less than that :) but I'm a speed freak. _a > 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 mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
From: Peter B. <re...@f2...> - 2001-05-20 07:02:35
|
At 02:02 PM 5/19/01 -0700, you wrote: >uh, so if I can huff-and-puff for a moment, I really haven't seen anyone >even trying something as deep as r2 with php. that wasn't really true of r1, >i.e. it had tools that existed elsewhere in different code - but r2 is >entirely unique. Uh-huh. Just to throw in an odd question: why write a program such as Binarycloud in PHP rather than C/C++? >Once we get a functioning r2 install, we're going to start in on a cms >immediately, would you like to participate in its development? I'd love to. I think my skills are developed enough to do this - I don't think they are for writing the BC core - or I wouldn't like to attempt it :-( Still, once my exams are over for another year I'll be able to dedicate my time to programming ;-) >I think pear has a caching class, so we might just be able to plug it in! Ulf Wendel wrote it, so it should be good. The other one people seem to like is phpCache, which would be worth a look. >that means you can (fairly easily) wrap lightweight applications, as long as >they don't try to start a session. Why? If you called ob_start() wouldn't that solve the problem? >also, with the stuff we're doing, it will almost be easier to re-build a >simple app than to port it in. I think you're right. One last question: how does binarycloud compare to something like the Midguard project? Peter. -oOo- Maple Design - web design, hosting, domain names http://www.mapledesign.co.uk -oOo- |
From: alex b. <en...@tu...> - 2001-05-20 18:06:47
|
> Uh-huh. Just to throw in an odd question: why write a program such as > Binarycloud in PHP rather than C/C++? Time. the reason they wrote php is because writing web apps in c++ takes so much time as to be unreasonable. you shouldn't have to worry about memory management when writing web applications. yeah, c is faster, but we're talking about faster than really fast :) java was a no-go because is is actually almost as expensive to develop with than c++, it's not really _designed_ for doing web development specifically. > I'd love to. I think my skills are developed enough to do this - I don't > think they are for writing the BC core - or I wouldn't like to attempt it :-( > Still, once my exams are over for another year I'll be able to dedicate my > time to programming ;-) cool :) > Why? If you called ob_start() wouldn't that solve the problem? because those apps tend to think the session name is phpsessid, and a bunch of other things. that was offhand, there are definitely ways of making it work. > One last question: how does binarycloud compare to something like the > Midguard project? Midguard is a CMS. one of the binarycloud modules (or more correctly, a couple of the modules) will combine to form a CMS. the difference is that bc is designed to support anything php supports, it's not an isolated app with some supporting infrastructure. _alex |
From: Nico G. <sc...@ac...> - 2001-05-21 00:42:36
|
--* alex black (Sun, May 20, 2001 at 11:04:30AM -0700) *-- > Midguard is a CMS. > one of the binarycloud modules (or more correctly, a couple of the modu= les) > will combine to form a CMS. Just took an rather extensive look at their tour and docs. It seems to be pretty mature stuff, and I see some very interesting and complex cms features in there (user groups, locking, domains, approval, database replication). Looking at the API, i think implementing this as a bc module wouldn't be as hard as it may seem. Although alot of the functionality in both systems will overlap ofcourse... --nicolas -- nico galoppo - tremelo/leuven, belgium - erasmus/socrates student in grenoble, france - 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19 --------------------------------------------------------------- [bash]:~$ man woman nico at crossbar dot net No manual entry for woman debian linux :: vim powered |
From: Alex B. <en...@tu...> - 2001-05-21 00:59:27
|
> Just took an rather extensive look at their tour and docs. It seems to > be pretty mature stuff, and I see some very interesting and complex cms > features in there (user groups, locking, domains, approval, database > replication). user groups --> don't need locking --> this is nice domains --> this is nice approval --> this is nice database replication --> this is nice, but if we were to do it, I'd want to do it through metabase. I'd have to read more about what they do with this, but it occurs to me as something that you would want to be a function of your database install, not your app code. > Looking at the API, i think implementing this as a bc module wouldn't be > as hard as it may seem. Although alot of the functionality in both > systems will overlap ofcourse... I would need to look at the code, but this sounds cool. If it ends up being a pain to try and track stuff down, we can use some of their "methods" that we like :) _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Nico G. <sc...@ac...> - 2001-05-21 06:22:22
|
--* Alex Black (Sun, May 20, 2001 at 05:58:31PM -0700) *-- > user groups > --> don't need why's that? think about having documents that you want a group of users to be able to edit/lock/view etc? i can understand user 'levels' can partly solve this problem, but what about user joe in group foo and group bar and user claire in group bar and group stuff.=20 a document available to group bar would be for both of them, the one in group stuff would only be for claire. with levels, claire and joe can't have both common *and* exclusive documents, unless you link the userid to the document itself. or did i get lost somewhere underway? > > Looking at the API, i think implementing this as a bc module wouldn't= be > > as hard as it may seem. Although alot of the functionality in both > > systems will overlap ofcourse... >=20 > I would need to look at the code, but this sounds cool. >=20 > If it ends up being a pain to try and track stuff down, we can use some= of > their "methods" that we like :) indeed. for example, using a common user 'id' base would make it all pretty easy (for example grouping bc users & authentication into a midgard user tree) --nicolas -- nico galoppo - tremelo/leuven, belgium - erasmus/socrates student in grenoble, france - 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19 --------------------------------------------------------------- [bash]:~$ man woman nico at crossbar dot net No manual entry for woman debian linux :: vim powered |
From: alex b. <en...@tu...> - 2001-05-21 06:37:42
|
> why's that? think about having documents that you want a group of users > to be able to edit/lock/view etc? i can understand user 'levels' can > partly solve this problem, but what about user joe in group foo and > group bar and user claire in group bar and group stuff. no, not "we don't need that at all" we have that. it's burrly. it works :) > a document available to group bar would be for both of them, the one in > group stuff would only be for claire. with levels, claire and joe can't > have both common *and* exclusive documents, unless you link the userid > to the document itself. right, this is all doable within the current system. > or did i get lost somewhere underway? no. > indeed. for example, using a common user 'id' base would make it all > pretty easy (for example grouping bc users & authentication into a > midgard user tree) I think I need to install midguard :) _alex |
From: Nico G. <sc...@ac...> - 2001-05-21 07:21:50
|
--* alex black (Sun, May 20, 2001 at 11:35:24PM -0700) *-- > > indeed. for example, using a common user 'id' base would make it all > > pretty easy (for example grouping bc users & authentication into a > > midgard user tree) >=20 > I think I need to install midguard :) well, i just got scared by it ;) it's got a dynamic library part, a php module and an apache module ...=20 otoh, is the source for bc_edit available somewhere? --nico -- nico galoppo - tremelo/leuven, belgium - erasmus/socrates student in grenoble, france - 4, rue b=E9ranger -- phone: +33-(0)76-85 23 19 --------------------------------------------------------------- [bash]:~$ man woman nico at crossbar dot net No manual entry for woman debian linux :: vim powered |
From: Andreas A. <a.a...@th...> - 2001-05-21 10:36:10
|
Hi Alex, user groups --> don't need Don't agree. I think user groups are essential. Imagine a module called "forum". It's a generalized module implementing the forum functionality. You have db tabels for lets's say "forum_posts", "forum_categories", "forum_logs", "forum_topics" and "forums". So having usergroups (that holding the permission pattern) you can use them for assigning some forums to the group "developer" other to "user" some to "anonymous" so that they can't be accessed by the other group. If you need more, take Workspaces. Workspaces can combine usergroups or users. So a workspace called "Customers" contains the usergroups "ad clients", "normal clients", "web clients" or whatever, another "intranet" contains your intranet users. So forums belonging to the workspace "Customers" are available for all users beloning to "Customers". This applies also for documens etc. Groups may also be interesting in mapping unix groups to the database. Don't especially know a application for that, but I think sourceforge does this way. Maybe this is all a bit complicated and narrow-minded. But I think there is a real usage for usergroups. Workspaces maybe interesting for the CMS module. Andi |
From: alex b. <en...@tu...> - 2001-05-21 15:22:07
|
> > Don't agree. I think user groups are essential. Imagine a module called > "forum". It's a generalized module implementing the forum functionality. You > have db tabels for lets's say "forum_posts", "forum_categories", > "forum_logs", "forum_topics" and "forums". So having usergroups (that > holding the permission pattern) you can use them for assigning some forums > to the group "developer" other to "user" some to "anonymous" so that they > can't be accessed by the other group. We don't need _midguard's_ user groups, as bc r1 already has that, and r2 will have an expanded/groovier version of it. So I'm not saying "user groups are dumb" which would be, well, dumb. I'm saying that we already have this and don't need to go looking elsewhere for it. > If you need more, take Workspaces. Workspaces can combine usergroups or > users. So a workspace called "Customers" contains the usergroups "ad > clients", "normal clients", "web clients" or whatever, another "intranet" > contains your intranet users. So forums belonging to the workspace > "Customers" are available for all users beloning to "Customers". This > applies also for documens etc. The functional elements in r2 auth/perm are users/roles. We could easily add a faux hierarchy to that, i.e. be able to classify users in groups simply to make them easy to deal with. I like that idea, it will probably be added as part of the entityEditor. > Groups may also be interesting in mapping unix groups to the database. Don't > especially know a application for that, but I think sourceforge does this > way. At an even lower level, there are pam modules for doing db auth in unix machines, SF uses ldap because of the number of users - which is nice. I think it's called pam_ldap > Maybe this is all a bit complicated and narrow-minded. But I think there is > a real usage for usergroups. Workspaces maybe interesting for the CMS > module. User groups are absolutely necessary. But we don't need midguard's :) _a |
From: alex b. <en...@tu...> - 2001-05-21 15:15:18
|
> otoh, is the source for bc_edit available somewhere? I will do this as soon as I get into the office. _alex |
From: Peter B. <re...@f2...> - 2001-06-02 11:31:54
|
At 08:13 AM 5/21/01 -0700, you wrote: > > otoh, is the source for bc_edit available somewhere? > >I will do this as soon as I get into the office. where could I donwnload a copy please? I can't find it on sourceforge or at bc.com Thanks, Peter. |