Re: [Phpgroupware-developers] Addbook vs addressbook

[Alex Borges (lex)]

IM sorry ive been away and not answering much.... ill be back in active
duty shortly, hopefully with some workforce too....



Adam. Phpgroupware or axisgroupware are not, cannot be, just hubs for
applications. An simple addressbook as an inventory of contacts is not a
groupware app. Hell, its not even a groupware component. 

The important part about this addressbook discussion is NOT addressbook
vs addbook, it is the contacts backend and what can be done with it to
really give features of a groupware api to other applications, one of
them could be a nice contact management app, or a CMS, or a simple
contact inventory.

If you need just a contact's inventory, BY ALL MEANS, grab addbook. This
doesnt mean that those contacts can have any mapping to users, or that
the organizations in the org table can be phpgw groups (or categories),
or that the solution youll be deploying can be integrated into an
existing corporate directory. Just a contact inventory, thats it.


Thats what this discussion is about, and i have been following, just
havent had the time to participate actively (and responsively, i just
dont want to keep moving the mud without being an active code
contributor, and this past weeks i just couldnt). 

So i take this oportunity also to state my position on the matter. I
agree with ralph in all repsects:

Normalized Data Org -< ppl relationship (at least), somehow mapped as
good as possible in ldap, giving priority to the usability of the
contact's backend, regardless of ldap's data representatiuon
limitations. That is, let the ldap users (and im one of them, or wish to
be anyhow) worry about having the CMS working fine with an ldap as
backend. The important part to consider is the desing of the app, the
CMS potential and the correct integration of the contacts to the
userbase (user - contact relationship, for which ldap is ideal, for
example). 

The fact is that no groupware api/suite can be independent of a central
directory of contacts (thus, you cant go and implement your coporate
directory in sql, have api/backend integrated in the framework that
bases upon the directories data, and still claim the deployed solution
will scale to solve other problems). I think ralph is correctly assesing
and accepting the existing problem with addressbook,  the reasoin why
addbook was created and is popular, but i also think that in this list
he has been talking about a solution. He also put up a wiki for
discussion (which i havent been able to revise either), and i suggest
all interested go there asap and read it before engaging in efforts that
dont offer a general solution.
 
 

El jue, 20 de 03 de 2003 a las 17:32, Adam Hull escribió:
> I have reread through this thread and wanted to add a few things, but first I 
> want
> to say that the following is in no way a criticism, I am simply stating my
> perspective on the addressbook situation.
> 
> I have personally given up on LDAP. This is mostly because I just do not need 
> it. I
> am mostly using phpGroupware for small groups. So, I do not need LDAP auth 
> since
> none of my installations will span more than one server. I was hoping to have 
> an
> addressbook with LDAP support so users could use an LDAP client if they 
> wanted to,
> but I can live without that. I just cannot wait any longer for it to be 
> implemented.
> And from the sound of this conversation, the problem with storing relational 
> data in
> LDAP is going to make this exceedingly difficult, delaying this project even 
> more.
> So, not having LDAP as a requirement, my needs are much simpler.
> 
> I have detailed my needs in the phpgw wiki page under "addbook" here:
> http://docs.axisgroupware.org/index.php?page=phpgroupware0916
> If you would like to add your needs, feel free to do so there, but I will 
> list my
> needs here as well:
> 
>           o CSV file importing directly into addbook with field mapping
>           o Ability to add custom data fields
>           o Improved interface along the lines of how infolog works
>           o A preference for the user to use a mail client or phpgw email 
> which
> changes the link from "mailto:"; to a link to phpgw email when email addresses 
> are
> displayed
> 
> These needs are based on "addbook". For my purposes, addressbook is unusable. 
> I need
> person/organization separation like many others do. So, it would be easiest 
> for me
> to make a few modifications to addbook to reach my goal. But, I have no 
> interest in
> maintaining my own application, so I would like to contribute to this project 
> if
> possible.
> 
> Correct me if I am wrong, but it sounds as though development will continue 
> with
> addressbook, merging addbook's features into addressbook. This sounds a little
> backwards considering addbook is more normalized. And a migration path has 
> more or
> less been written for moving from addressbook to addbook. Wouldn't it be 
> easier to
> build on addbook?
> 
> What exactly is the roadmap for this? Will the new addressbook be built from
> scratch? built on addressbook? or built on addbook?
> 
> Please let me know if I can help.
> 
> Adam Hull (fixe)
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
-- 
Alex Borges (lex) <address@hidden>
Step One Group