8418 - [LDAP] LDAP should linkify values

Status: NEW

(MailNews Core :: LDAP Integration, enhancement, P3)

Description

[Phil Peterson]

In Communicator 4.x, when we display an LDAP entry in HTML, we consult a
preference to see which attribute names are really URLs. The Admin Server
implements dynamic mailing list (a list whose members are defined on-the-fly by
an LDAP query) using an attribute called "mgrpdeliverto". The value of
mgrpdeliverto is an LDAP URL. We could fix this problem in one of two ways:

1. Scan all the values coming back from the LDAP server to see if they're URLs

2. Add some more attributes, like mgrpdeliverto, to the list of attributes we
know are URLs (as with labeleduri)

Comment 1

[David :Bienvenu]

move to m12, since Phil won't be back until m10

Comment 2

[sol]

Since we won't have LDAP for PR1, I don't think this bug needs to be fixed for
PR1

Comment 3

[Phil Peterson]

Might be nice to take option (2) and use the code RichP wrote for libmime
linkifying as a service or something.

Comment 4

[selmer (gone)]

Phil found a way to weasel out of owning this bug.  Reassigning.

Comment 5

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 6

[selmer (gone)]

[LDAP] in summary

Comment 7

[selmer (gone)]

LDAP to M30, nobody, helpwanted

Comment 8

[Ben Bucksch (:BenB)]

Refers to 4.x, but the same would make sense for Mozilla. Just run the values of
all field through ScanTXT, so we can pretty them up (e.g. linky URLs).

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Maybe the right thing to do here is make sure nsLDAPChannel is outputting clean
LDIF format, and then make an LDIF->HTML stream converter.  Or potentially even
LDIF->DSML, and have some decent stylesheet for that.  But first we have to get
the code in the channel cleaned up enough to turn on in default builds, and
there's still a little ways off.

Comment 10

[Ben Bucksch (:BenB)]

Yup, if you have enough (unambiguous) info for that. You may still want to run
the plaintext parts (e.g. freetext comments) through ScanTXT.

Comment 11

[Gervase Markham [:gerv]]

[Disclaimer: I'm coming very late to this bug. Thanks for the CC, though. ]

Surely we want to stick with Moz-native formats (i.e. XML) as much as possible? 
Ideally, we'd output DSML, and stylesheet/XSLT that to HTML, or convert to LDIF. 
Maybe?

There might be a slight snag in that DSML is a bit brain-dead in certain areas, 
and may not contain enough information to make this practical...

Gerv

Comment 12

[Phil Peterson]

> Maybe the right thing to do here is make sure nsLDAPChannel is outputting 
> clean LDIF format, and then make an LDIF->HTML stream converter.

Are you saying you're going to take the time to generate LDIF just so you can
take more time to parse it? Wouldn't it be faster just to go straight from the
binary LDAP SDK APIs straight to whatever we want? Of course, we'd use ScanTXT
in either case.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

Well, the deal is that nsLDAPChannel.cpp already generates LDIF (more-or-less)
because the format was so drop-dead simple to generate that's what I wrote (I
also didn't know about the existence of DSML at the time).  I'm not terribly
attached to keeping it the way it is, though it might be handy for future
Mozilla-as-platform considerations both read and write LDIF.

Comment 14

[Gervase Markham [:gerv]]

Forgive me for being a little confused, but I can't see any references to LDIF 
in nsLDAPChannel.cpp. Are they elsewhere?

<rant>
Searching LXR for filenames with LDIF in produces spf2ldiff.c. What sort of 
person writes an entire file of code with zero comments and one-character 
variable names?
</rant>

Gerv

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Gerv: it's not explicitly mentioned in nsLDAPChannel that the format being
output is LDIF (yeah, it should be).  But it is.  The format for search output
is really simple:

dn: *some dn goes here*
attribute1: value1
attribute2: value2

etc.

Comment 16

[thebeastwitheyesthatstared]

is this bug still relevant? (bug cleaning)