[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]Distributed Savannah(was: phpGW and DotGNU)

From: David Sugar
Subject: Re: [DotGNU]Distributed Savannah(was: phpGW and DotGNU)
Date: Thu, 15 Nov 2001 10:19:40 -0500 (EST)

I am also looking at the PHPgwAPI, to use in building Bayonne web
services, as well as looking at how we can make Bayonne applications that
integrate well with existing phpgroupware modules, although my time in
this area has been somewhat limited.  The core parts of phpgw are quite
useful for building these kind of things, and I can appreciate why Loic is
thinking this way about Savannah "II".


On Thu, 15 Nov 2001, Dan Kuykendall (Seek3r) wrote:

> "Gopal.V" wrote:
> >
> >         phpGroupWare is great but for a project management and development
> > service, I believe Savannah is better. Personally I was blown away when
> > phpGW showed the current weather at Thriuvanthapuram correctly ( I later
> > learnt that the `VOTV' metar is used ). Savannah has no need or use for
> > such services.
> phpGroupware is a not one big program. It is the API and setup program
> along with a collection of applications/modules that all use the API.
> The weather program is just an optional component as are every other
> program. Its is possible to simply take the phpgwAPI and and the
> calendar app if you wanted. So you are right, there is no real reason
> savannah would bother installing the weather application/add-on.
> > So rather than hacking phpGW into a Savannah clone, we
> > should plan things so that when you visit your profile @ Savannah,
> > It retrieves the data/VCard using XMLRPC from your phpGW profile.
> > And conversely, let you see mentions/comments of your latest project
> > @Savannah in your online resume @ phpGW. [ Sorry if this seems redundant ]
> The current plans are not so much to use phpGW as a groupware system.
> The key thing that savannah wants is to use our API. Our API (called the
> phpgwAPI) is extremely modular. Each of the services provided by the api
> are abstacted to allow the data store to be changed out without
> effecting any other parts. Some of the services the api provides are:
> database abstraction (mysql, pgsql, oracle and mssql), account services
> (sql and ldap), preferences (sql and ldap), authentication services
> (sql, ldap, imap, http_auth and we plan on adding support for some
> DotGNU auth standards), Access Control List [ACL] security (SQL only at
> this point), Virtual File System [VFS] (Files/Dirs, and CVS storage is
> in development), XML-RPC, SOAP(in dev), templatized HTML, and a few
> others I am forgetting at the moment.
> So these are the things that savannah wants. They will also be able to
> take and tweak some of our current applications to suit fill in the
> rolls of the applications in the sourceforge software.
> One of the tools for instance is the bug/feature tracking tools on
> sourceforge called the tracker. We have a tool we call the Trouble
> Ticket System (or TTS) which does the same thing. However ours has an
> XML-RPC interface and with this the lead developer is about 3 days from
> having a working X-Windows client written in Klyix that supports the
> TTS. So developers wont need to open their web browser, goto
>, login, click to their project home page, click on the
> link to bug tracking and *finally* start work on the bug reports. The
> will be able to load up their Klyix client and click "login" and get to
> work on the bugs.
> This is only an example, but it demonstrates that phpGW is already a
> working web service and why Loic wants to use phpGW as the foundation
> for his next generation savannah.
> > I looked up Macs a bit, it divides the authentication into watertight
> > compartments. I think someone will need to make the phpGW authentication/
> > authorization using pluggable modules. ie just as database calls are 
> > abstract
> > in the current phpGW. This will make sure that it can act as AUC,LMC,UPC and
> > ATC ( refer Macs ). I have no doubt that Savannah will adopt such a 
> > brilliant
> > Single Login scheme. As far as I have seen, this is far better than 
> > Hailstorm.
> > If both of them can act as the Macs client modules, we have a single login
> > for phpGW and Savannah, provided they have the same AUS etc. ( I am still
> > unclear about this, does Macs authorization dissapear when you switch AUSes 
> > )
> It will be no problem to support whatever authentication and single sign
> on mechanism you want. As long as we can get the token and verify it
> againt the auth service we will be fine. I know this may seem odd but I
> wanted to see how far I could go with our authentication abstraction,
> and I was able to use PHP's COM support to authenticate againt a
> WindowsNT domain server. I will probably include that into phpGW as I
> work out a few bugs... but our authentication system is super simple and
> should work with any DotGNU solutions.
> Seek3r
> _______________________________________________
> Developers mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]