[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-developers] [Phpgroupware-users] Modularised OO - Develope
From: |
Alex Borges |
Subject: |
[Phpgroupware-developers] [Phpgroupware-users] Modularised OO - Developers discussion |
Date: |
Wed, 12 Jan 2005 10:51:20 -0600 |
User-agent: |
Mozilla Thunderbird 0.9 (X11/20041124) |
<snip/>
The way I see PGW is a core set of API (such as user authentication, cookies
handling etc) and a number of potentially powerful applications.
<Snip/>
Ok.... Chriss already outlined that we all agree (or have agreed at some
point) to the design principals you so carefully laid down in the
previous email.
This part though, especially the 'potentially powerfull' applications is
really what we have been concentrating on for the past couple of
years... .that is, to move some more of the core groupware logic into
the api so it can be used by other apps so the potential of each true
core groupware component can be unleashed when its logic is exposed to
other apps, which are the ones that should be bringing most of the value
to the platform.... Like projects, sitemgr or CK.
The first example of what weve tried is the contacts backend. All its
core logic is in the api, accesible from the contacts_sql class. We had
it the same way before the new backend (which is more complex than what
we had before), but this time we really made a point of it being usable
from other apps as the core backend for managing people and organizations.
So the idea is now to use that as the core for most things that have to
do with people. Like, we should be setting appointments in the calendar
with people (using the contact_id), not with accounts (using the account
_id).... that sort of thing. Also
Also, the contacts backend has potential to expose communications data
for each contact, person, organization or user so that an application
that say, sends messages to people when an appointment is abbout to
expire, can consult the contacts backend to see what IM service, email
address, fax number or phone does the contact prefer to be contacted by.
In the future the idea would be to hook up gateways to this
communication systems. The easy ones would be the instant messenging
services and emails, then we could have a text2speech gateway that
talked to a phone (part of that has been experimented by dave hall, i
understand, with VOIP + contacts -although not the automatization part).
I personally think the calendar is a huge thing that could provide tons
of value to other apps. I think its logic to set, delete, update
appointments and attach alarms to them should also be in the api and
extended so that it was a true schedulling service which may have, as an
application, a visual web-based calendar.... or a gantt chart
renderer... or both... etc.
Another step in this value integration to the api was taken by the
probiz crowd. This guys made a generic infrastructure for
syncronization, then they made it speak xml-rpc, then they used a known
great client for the syncml protocol.
The generic syncronization infrastructure they made, well they claim
they made it only for syncml, but its design is so good that it can be
used to sync from/to other sources... and even as a generic
syncronization api for phpgroupware's core applications.
This also is being put into the api (to an extent) and plans to use it
for a bunch of interesting things are in progress..
So.... the immediate steps for phpgroupware is to move all this stuff we
already have into the api or applications to be used by other
applications thus lending value to the next release of the platform.
More into the future, the nextgen branch experiments with a bunch of new
web technologies and a full rewrite of the api, free of the atavisms of
20th century web development (i allways wanted to say something like that).
So, wellcome, check it out..... we wellcome help allways.
alex.vcf
Description: Vcard
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Phpgroupware-developers] [Phpgroupware-users] Modularised OO - Developers discussion,
Alex Borges <=