On Tue, 2002-11-19 at 14:27, Dieter Kluenter wrote:
> Hi,
> 
> Chris Toshok <[EMAIL PROTECTED]> writes:
> 
> > On Tue, 2002-11-19 at 06:34, Dieter Kluenter wrote:
> [...]
> > please don't compress attachments - can't expand inline if you do.
> 
>  I'm so sorry and I will not do it again , but on most mailing lists
>  you get flamed if you don't compress your attachments. :-)
> >
> [...]
> > The calendar/fb stuff was added before I knew about rfc 2739, and
> > unfortunately it's not a good idea to remove attributes from publicly
> > distributed schema - they're deprecated, and the file actually says
> > "don't use these, use the attributes in rfc2739."
> 
> I understand these arguments, on the other hand, that has been one of
> the reasons for writing a new schema file as I couldn't find an
> apropriate file. 

They're listed in the rfc, sections 2.4.3 (for the objectclass) and
2.4.4 (for the attributes.).  I just pasted it all into a file here..

> > I'll probably adopt your SUP changes for phone/fax/address..  If only
> > evolution supported queries of that sort.
> 
> I'm not a code maniac but I would like to support propper ldap support
> in evolution.

It sucks, but I'm not sure it's even something we could do well - I mean
it would be *much* nicer to search using (name=*toshok*) instead of
(|(cn=*toshok*)(sn=*toshok*).....)  but the trouble with that is that we
don't display every possible field, and people might have unsupported
(to evolution) attributes that also subclass from name.  So you'd end up
with things in the display that don't contain anything visible that
would match the query.

Of course we could do the general query and then do more specialized
checks locally, but that doesn't work well in the face of query size
limits (since our result set might be much larger before pruning
locally).

Chris

_______________________________________________
evolution maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution

Reply via email to