Menu
▾
▴
phpwebsite-developers — For our development team.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
| 2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
| 2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
| 2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
| 2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: clayton c. <cc...@ca...> - 2001-04-25 18:38:20
|
Todd, > > I downloaded ACS 4.2 last night, since Ars Digita improved the structure > since the 3.x series. Since it's in TCL, it's taking a little longer to > review than php or java projects. > for the most part, you can get a fairly good overview of the system by reading the online docs (very good) at www.arsdigita.com/doc . there is a section that details the design considerations and requirements for the permissions system. also look in the tarball directory acs/packages/acs-kernel/sql for the data model. this should give you a jump-start. clayton |
|
From: Todd O. <to...@da...> - 2001-04-25 18:17:02
|
Karsten wrote: > That does in no way contradict! You can register custom session data > storage containers with the native PHP4 sessions. So you can count the > records, and still use the natvive sessions. No problem :-) You can indeed select an alternative to /tmp/ file storage of session_id's in PHP4 using the native session routines. However, this requires access to the php configuration files, which many web hosting companies don't offer. Furthermore, you don't get the flexibility (in my opinion) of a session class you design yourself. --Todd |
|
From: Todd O. <to...@da...> - 2001-04-25 18:06:30
|
Clayton, I downloaded ACS 4.2 last night, since Ars Digita improved the structure since the 3.x series. Since it's in TCL, it's taking a little longer to review than php or java projects. I don't think we should have a group field in the main users table because we need a more robust system. That's why I like NT's access control lists over the simple UNIX file permissions (owner, group, everyone). Stay Tuned. --Todd |
|
From: clayton c. <cc...@ca...> - 2001-04-25 15:51:39
|
Todd,
the other thing to consider is maybe having group as well as user level
preferences. for example, if we have a group calendar, the group admin may
want to have a way of specifying preferences. so we can add a group_id
field, and we'll know which type preference it is by which field is not
NULL.
BTW - how far along are you with the SE document you were preparing ? i
want to begin putting something together about permissions and access
control, but that depends in part on how "OU" (as you called them) are
organized.
clayton
|
|
From: clayton c. <cc...@ca...> - 2001-04-25 15:42:22
|
Jason,
im working on specs for security (actually access control). we can handle
security in a way that does not require each table to have an additional
security related table. check out Todd's website for the translations i did
of ACS's 3.x permission system. it handles security in a much more granular
way than just the "seclevel" way.
the benefit of this approach is that the module writer simply has to
define a set of permissions for the module (maybe in a module XML
description file), and the security admin code can handle everything else in
a generic way. In other words, the module writer can simply write the module
and not have to worry about implementing his/her own code for setting up
permissions.
while on the subject, how are we segmenting admin "levels"? my thought
is site admin, group admin, maybe module admin, and if we decide to do
multiple sites per install, "super" admin
|
|
From: Karsten D. <k.d...@tu...> - 2001-04-25 15:41:36
|
On Tue, Apr 24, 2001 at 09:46:20PM -0400, Todd Owen wrote: > Does everyone plan to use this module (which I think is neat by the way)? >=20 > I'm asking because the Roadmap is to use native php4 sessions. However, = if > most everyone plans to use this module, we may want to reconsider using a > database backed session object like ezPublish has. Thoughts? That does in no way contradict! You can register custom session data storage containers with the native PHP4 sessions. So you can count the records, and still use the natvive sessions. No problem :-) Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
|
From: Jason C. <cam...@xp...> - 2001-04-25 02:17:33
|
I would think the table naming should sort of be consistent so you can tell which tables are for modules. Like say for the calendar it would be mod_calendar_user_options or just mod_calendar_opts or something like that. I think thats what we have right now in place for modules. At least the new calendar module and a few others I've been working with do it that way right now, which, to me seems like a good naming convention. What we dicussed earlier, we were thinking about either having one table to have the security info for all the modules or 1 for each module. Not sure which would be best right now. I've been thinking about the modules in general terms. IF each module would have a security table, it would have to be named like the module tables of course, say mod_calendar_admin or something like that and the table structure could be something like below to some degree. table: mod_calendar_admin user_id REFERENCES users.user_id (foreign key to core users table) seclevel INTEGER something something something else.... Some of this would depend on how involved the module actually is. Like the calendar would be a major module in the overall portal and might have different admin features or just one global one, based on whatever the module writer sees fit.... -- Jason Campbell Xplozive Media Technologies www.xplozivemedia.com phpWebSite Developer > As I posted to the website tonight I just thought about something we > need decide. How will user level module options be stored? I'm > thinking of a module level table as follows (assuming calendar module): > > table: calendar_user_options > user_id REFERENCES users.user_id (foreign key to core users table) > option INTEGER or TEXT (as decided by the module designer) > > --Todd > > |
|
From: Todd O. <to...@da...> - 2001-04-25 01:48:51
|
Does everyone plan to use this module (which I think is neat by the way)? I'm asking because the Roadmap is to use native php4 sessions. However, if most everyone plans to use this module, we may want to reconsider using a database backed session object like ezPublish has. Thoughts? --Todd |
|
From: Todd O. <to...@da...> - 2001-04-25 01:38:48
|
As I posted to the website tonight I just thought about something we need decide. How will user level module options be stored? I'm thinking of a module level table as follows (assuming calendar module): table: calendar_user_options user_id REFERENCES users.user_id (foreign key to core users table) option INTEGER or TEXT (as decided by the module designer) --Todd |
|
From: Todd O. <to...@da...> - 2001-04-25 00:40:17
|
Great. I'm all for ending each code file with (.php). It allows vi to get the syntax highlighting done automatically. Will we use .tpl for templates or how about .tpl.html? --Todd |
|
From: Jason C. <cam...@xp...> - 2001-04-24 22:18:12
|
I'm evaluating the drupal code right now (drop.org). I think I was the one that brought that one up for the plug-ins (modules). I like the way it does alot of things. I'd like to take that code and add some more backend to it and use that in phpWS II for sure. I've been studying it and working with some hybrid concepts of some of the drupal concepts in the phpWS CVS code, and right now the hybrid code works alot nicer than the current plug- ins. IMO...I'm just doing concepts of alot of the code right now. Nothing is even close to being finalized since nothing else is started for phpWS II yet :) -- Jason Campbell Xplozive Media Technologies www.xplozivemedia.com phpWebSite Developer > I'd just like to share something... as we've all been reviewing > other > projects and selecting ideas from them, much of what we're learning is > getting lost in the list, especially if new dev'rs come along... (e.g. > i recall drop.org has a nice way to automatically initialize/remove > modules, but can't remember if there are other projects that do the > same thing, or better, etc) > It would be nice, and I would like to organize a _SHORT_list/table > highlighting features from each valid project that we would like to > incorporate into phpWSII. > Then each dev team/person could reference such a list and maybe find > a link to that project's code, docs, phpWS dev notes, blah, etc... Some > are following other projects more closely or have a better grip on a > certain project's code, this should simplify referencing/discussion... > While it might seem like more organizational fooey right now, i believe > it would save much time and make for better discussion down the road, > IMO. > Any ideas on this?... please comment. > Cheers -WD > > __________________________________________________ > FREE voicemail, email, and fax...all in one place. > Sign Up Now! http://www.onebox.com > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: W.D.Sumilang <wa...@on...> - 2001-04-24 21:38:29
|
I'd just like to share something... as we've all been reviewing other projects and selecting ideas from them, much of what we're learning is getting lost in the list, especially if new dev'rs come along... (e.g. i recall drop.org has a nice way to automatically initialize/remove modules, but can't remember if there are other projects that do the same thing, or better, etc) It would be nice, and I would like to organize a _SHORT_list/table highlighting features from each valid project that we would like to incorporate into phpWSII. Then each dev team/person could reference such a list and maybe find a link to that project's code, docs, phpWS dev notes, blah, etc... Some are following other projects more closely or have a better grip on a certain project's code, this should simplify referencing/discussion... While it might seem like more organizational fooey right now, i believe it would save much time and make for better discussion down the road, IMO. Any ideas on this?... please comment. Cheers -WD __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com |
|
From: clayton c. <cc...@ca...> - 2001-04-24 15:04:58
|
> We need to decide on the following standards: > > What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. i suggest included.inc.php - the php at the end for security, and the inc to let us know what it is > What file extension will we use for classes? > included.class, included.class.php, etc.? probably .class.php . we dont want to confuse people with Java background. > Can we change the term plug-ins to modules? +1 |
|
From: Alain F. <al...@va...> - 2001-04-24 13:24:25
|
Re: [Phpwebsite-developers] Additional StandardsHello,
I absolutely agree. Sorry for the shortness of the mail, but there's nothing
more to add :)
-----Message d'origine-----
De : php...@li...
[mailto:php...@li...]De la part de
Aaron Adams
Envoyé : mardi 24 avril 2001 15:08
À : php...@li...
Objet : Re: [Phpwebsite-developers] Additional Standards
In my experience, using a semantic naming convention works best for CSS
.class names (that is, your descriptors should denote functionality).
Example:
.smaller = INCORRECT
.copyright = CORRECT
.big5 = INCORRECT
.subtitle = CORRECT
Not only is it easier for someone to understand a site's style at a
glance, but a semantic naming convention will help identify content for
future XML applications. Thoughts?
---
Aaron Adams
From: Karsten Dambekalns <k.d...@tu...>
Organization: fishfarm
Reply-To: php...@li...
Date: Tue, 24 Apr 2001 13:08:41 +0200
To: php...@li...
Subject: Re: [Phpwebsite-developers] Additional Standards
On Mon, Apr 23, 2001 at 09:49:50PM -0400, Todd Owen wrote:
> Does anyone have a comprehensive set of CSS descriptors we should use?
> ex. .big, .red, .bigred, .path, .smallnav, etc.
> ezPublish has a good start. Should we use theirs?
> This will be a standard for the core and module programmers.
We (that is Frits Jensen, W.D. Sumilang and Karsten Dambekalns) are in
the process of developing a suggestion for this topic. If you all
could be patient a few more days, we will likely have something to
submit here...
Regards,
Karsten
--
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w³: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg
|
|
From: Aaron A. <aa...@wc...> - 2001-04-24 13:09:24
|
In my experience, using a semantic naming convention works best for CSS .class names (that is, your descriptors should denote functionality). Example:=20 .smaller =3D INCORRECT .copyright =3D CORRECT .big5 =3D INCORRECT .subtitle =3D CORRECT Not only is it easier for someone to understand a site's style at a glance, but a semantic naming convention will help identify content for future XML applications. Thoughts? --- Aaron Adams From: Karsten Dambekalns <k.d...@tu...> Organization: fishfarm Reply-To: php...@li... Date: Tue, 24 Apr 2001 13:08:41 +0200 To: php...@li... Subject: Re: [Phpwebsite-developers] Additional Standards On Mon, Apr 23, 2001 at 09:49:50PM -0400, Todd Owen wrote: > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. We (that is Frits Jensen, W.D. Sumilang and Karsten Dambekalns) are in the process of developing a suggestion for this topic. If you all could be patient a few more days, we will likely have something to submit here... Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
|
From: Karsten D. <k.d...@tu...> - 2001-04-24 11:10:14
|
On Mon, Apr 23, 2001 at 09:49:50PM -0400, Todd Owen wrote: > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. We (that is Frits Jensen, W.D. Sumilang and Karsten Dambekalns) are in the process of developing a suggestion for this topic. If you all could be patient a few more days, we will likely have something to submit here... Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg |
|
From: Jason C. <cam...@xp...> - 2001-04-24 10:34:01
|
(This is just my opinion) Once the the core dev group is named, then they could discuss getting the database and other features in place so the rest of the groups can get other things developed. Its all down-hill once the main core of the system is established. Once that happens, then the theme system, language system, etc will all fall into place. Once all the teams are named, they could start establishing feature sets, etc for their individual module group (auth, theme system, etc). I'm working on a new way of writing the plug-ins (modules). But I'm just working with concept ideas and other things until the major parts of phpWebSite II are decided. Theme system, language routines, etc etc will all have to be some what in place for anyone on the plug-in team to be able to really finalize coding on alot of the plug-ins (modules). Todd and I were discussing that the plug-ins (modules) could/should have their own template and language file. Thats almost a given for some if not all of the plug-ins (modules). So, that part of the plug-in code would have to be written once the theme (template) and language systems are in place. > Hello Todd, > > One note about the file extensions to use. We will have to pay > attention to them for security reasons. Most PHP configurations are > setup to only parse the .PHP extension. Now imagine a config.inc file > that contains database passwords and what not else... if you call it > from the browser, it is sent in clear text because PHP doesn't parse > the .inc extension. It might be obvious but I preferred to point it out > nevertheless. > > As for the CSS selectors and classes, shouldn't we first try to think > about the layout and then deduct what selectors we will need? If we are > first setting the selectors, we will maybe be limited in our layout and > design choices because we might not have "enough" selectors. Or we will > have too many, with some never being used at all? > > Regards, > > Alain > >> -----Message d'origine----- >> De : php...@li... >> [mailto:php...@li...]De la part >> de Todd Owen >> Envoyé : mardi 24 avril 2001 03:50 >> À : php...@li... >> Objet : [Phpwebsite-developers] Additional Standards >> >> >> We need to decide on the following standards: >> >> What file extension will we use for included files? >> included.php, included.inc, included.inc.php, etc. >> >> What file extension will we use for classes? >> included.class, included.class.php, etc.? >> >> Does anyone have a comprehensive set of CSS descriptors we should use? >> ex. .big, .red, .bigred, .path, .smallnav, etc. >> ezPublish has a good start. Should we use theirs? >> This will be a standard for the core and module programmers. >> >> --Todd >> >> P.S. Can we change the term plug-ins to modules? >> >> >> >> >> _______________________________________________ >> Phpwebsite-developers mailing list >> Php...@li... >> http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers >> > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Jason Campbell Xplozive Media Technologies www.xplozivemedia.com phpWebSite Developer |
|
From: Jason C. <cam...@xp...> - 2001-04-24 10:17:29
|
Todd, After we discussed a few of the things on the phone, I was thinking about having the current plug-ins stay as plugins. That would make it backward compatiable which is one thing in the Road Map. So if thats true, we leave the plug-ins as plug-ins and make a new group called "modules" and anything new we go towards being modules which will be a new "hybrid" of the current plug-in system. I've got the referrer as a plug-in NICE and clean now with everything for it in one file in its own plug-in directory using functions (which might change for the OOP way) and it works just fine. We can get rid of passing too many variables in the URL by using global variables for the features of the "modules". And for some reason I just mixed using "plug-ins" and modules but oh well :) > We need to decide on the following standards: > > What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. > > What file extension will we use for classes? > included.class, included.class.php, etc.? > > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. > > --Todd > > P.S. Can we change the term plug-ins to modules? > > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Jason Campbell Xplozive Media Technologies www.xplozivemedia.com phpWebSite Developer |
|
From: Alain F. <al...@va...> - 2001-04-24 07:02:04
|
Hello Todd, One note about the file extensions to use. We will have to pay attention to them for security reasons. Most PHP configurations are setup to only parse the .PHP extension. Now imagine a config.inc file that contains database passwords and what not else... if you call it from the browser, it is sent in clear text because PHP doesn't parse the .inc extension. It might be obvious but I preferred to point it out nevertheless. As for the CSS selectors and classes, shouldn't we first try to think about the layout and then deduct what selectors we will need? If we are first setting the selectors, we will maybe be limited in our layout and design choices because we might not have "enough" selectors. Or we will have too many, with some never being used at all? Regards, Alain > -----Message d'origine----- > De : php...@li... > [mailto:php...@li...]De la part de > Todd Owen > Envoyé : mardi 24 avril 2001 03:50 > À : php...@li... > Objet : [Phpwebsite-developers] Additional Standards > > > We need to decide on the following standards: > > What file extension will we use for included files? > included.php, included.inc, included.inc.php, etc. > > What file extension will we use for classes? > included.class, included.class.php, etc.? > > Does anyone have a comprehensive set of CSS descriptors we should use? > ex. .big, .red, .bigred, .path, .smallnav, etc. > ezPublish has a good start. Should we use theirs? > This will be a standard for the core and module programmers. > > --Todd > > P.S. Can we change the term plug-ins to modules? > > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Todd O. <to...@da...> - 2001-04-24 01:52:20
|
We need to decide on the following standards: What file extension will we use for included files? included.php, included.inc, included.inc.php, etc. What file extension will we use for classes? included.class, included.class.php, etc.? Does anyone have a comprehensive set of CSS descriptors we should use? ex. .big, .red, .bigred, .path, .smallnav, etc. ezPublish has a good start. Should we use theirs? This will be a standard for the core and module programmers. --Todd P.S. Can we change the term plug-ins to modules? |
|
From: clayton c. <cc...@ca...> - 2001-04-23 21:47:06
|
Todd, i just had another look at the data model for ACS4.0, and it looks like they did a lot of what you described in terms of Python's heirarchical system of permissions. it seems a bit more streamlined than the one i translated, but in doing so it uses syntax for heirarchical data retrieval (connect by, etc) which i dont think is supported by MySQL (dont know about PGSQL). i dont know how performance would fare if we did this in PHP. it also has the working of your idea of "relational-nodes" (basically anything can be related to anything else), along with the attendant code/model for metadata. this release also features their Content Management engine, the data model of which also makes for good reading. of course, its written in TCL and runs on Oracle, but the interesting thing is that the database code is written for Oracle packages, which makes it very nicely encapsulated and OOPish, so if you understand pl/sql (not difficult at all if you understand SQL) , you can easily translate the data model into some nice PHP classes. clayton |
|
From: W.D.Sumilang <wa...@on...> - 2001-04-23 19:10:00
|
RE: http://www.geocrawler.com/lists/3/SourceForge/9885/25/5535880/ Geoff, I'd like to know the reason why "it's a no-no"... while i agree that adding more requirements to phpWS would reduce its usability _for_some_people_ sometimes the end does justify the means (IMHO)... so if you could be so kind, or anyone for that matter, provide some insight to the validity of Geoff's security concern... as i've not been able to track down any security issues, then again maybe i'm not looking hard enough... thanks and cheers ;o) -WD __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com |
|
From: W.D.Sumilang <wa...@on...> - 2001-04-23 18:59:32
|
>>Anyway, even with my concept, there are still occassions where you will want two organizations to interchange data, whether or not they're in the same database or even the same server; this is where XML-RPC comes into play.<< Yes, aside from your specific example, there are many others, It's on my wish list to incorporate this into phpWS's schema. BTW, anyone planning on providing a graphical representation of phpWS's proposed architecture?... I like pictures ;o) -WD __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com |
|
From: Karsten D. <k.d...@tu...> - 2001-04-23 08:29:27
|
On Sun, Apr 22, 2001 at 11:48:36PM -0400, Todd Owen wrote:
> Roadsend introduces additional/custom tags into their templating scheme.
> Does anyone like this idea in lieu of the {braces} style?
I strongly discourage things like that. It makes it too difficult to
use standard editing tools (Dreamweaver etc.) to create
templates. This is something that I hoped to become possible by
introducing a new templating scheme.
Regards,
Karsten
--=20
Why do we have to hide from the police, daddy?
Because we use emacs, son. They use vi.
-----------------------------
mailto:k.d...@tu... w=B3: http://www.k-fish.de/
gpg: http://www.k-fish.de/mykeys.gpg
|
|
From: Todd O. <to...@da...> - 2001-04-23 04:47:19
|
From the posts this week, it seems that I may be the only one on board for the multiple sites in one database concept, so I'll table that discussion a little while. Anyway, even with my concept, there are still occassions where you will want two organizations to interchange data, whether or not they're in the same database or even the same server; this is where XML-RPC comes into play. http://www.xml-rpc.org Let's suppose I have (4) 25,000 member organizations (state universities without central control). Furthermore, two universities have separate LDAP authentication and the other two use a database (one MySQL and one Postgres). The physics professors from all four universities meet at a conference and decide that they will try to produce Cold Fusion again (the nuclear kind). Since Appalacian State's physics department is the most prominant, they will "host" this _collaboration_. How will UC-Berkley, Georgia Tech and MIT professors be able to login and post on App State's Cold Fusion site? Enter XML-RPC. Jeremy will create an associate member account (or whatever we decide to call it) for Dr. John Smith at MIT on App State's site (let's assume App State uses a MySQL member database). Wait, there are already two Dr. John Smiths at AppState already with usernames john_smith and john_smith2. Dr. Smith at MIT uses john_smith as his login. This special "associate" account will have username john_smith_mit, BUT MIT's Dr. Smith won't have to know that because he'll log in as john_smith from mit.edu. App State's phpWS will send a XML-RPC request to MIT asking for Dr. Smith's md5 password hash (this is for security purposes). This will only Authenticate Dr. Smith, assuming his password matches and his account is not disabled at MIT. Upon authentication, App State's permissions apply exclusive of any permissions he had at MIT. This separates the Authentication and Permission phases for MIT's Dr. Smith. By creating modules (which I like much better than plug-ins BTW) that support XML-RPC, separate phpWebSite installations can share and transfer data like the example I gave above. If Dr. Smith's password changes at MIT, then it's effectively changed at App State. Inter-university calendars could be done this way too. Similar systems exist to request the latest headlines form Slashdot and Freshmeat. Take a look at this XML syndication example if your browser can handle it. http://www.bsdtoday.com/backend/bt.rdf --Todd |
5 messages has been excluded from this view by a project administrator.
