ENOSIG Discussie (threads)


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

Re: LDAP in OCaml


On Mon, May 05, 2003 at 12:13:40AM +0200, Jama Poulsen wrote:
> On Sun, May 04, 2003 at 10:49:48PM +0200, Lionel Elie Mamane wrote:
> > On Sun, May 04, 2003 at 05:41:06PM +0200, Jama Poulsen wrote:
> > > On Sun, May 04, 2003 at 09:59:45AM +0200, Lionel Elie Mamane wrote:

>> What do you mean by "callback"? 

> This is a general programming concept

OK, you mean the general programming concept.

>> Please provide example code (in a human-readable pseudo-language)
>> using callbacks. I have the hunch that the library doesn't need to
>> do anything special, the language gives it to you.

> No, this is an API issue, you only need function reference support
> in the language. If a can't pass a callback reference in the OCaml
> module then it won't ever end up in the OpenLDAP function.

Yes, but what do you want to do with the function you pass? E.g. if
you do an LDAP directory search, should it be called on every result
of the search, or do you want to use it to do programming by
continuation?

 - Call on every result:

   Just use map or fold_left, it does the job

 - Programming by continuation

   All you need is a wrapper that calls the search, and then the
   continuation.

That's what I meant when I said "I have the hunch that the library
doesn't need to do anything special". And that's what I wanted to
check on the example code.

(If you start on efficiency arguments, yes, it would certainly be more
efficient to do the callback "directly" rather than construct the list
of results and deconstruct it, especially in cases where you'd use
fold_left. But except for memory pressure, I don't think the overhead
is that big in OCaml. Btw, this is where lazy languages (like Haskell)
shine: They give the programmer the ability to write "map", but get
the efficiency of the callback solution. But at the C level, the list
is constructed anyway, so in bindings of the C library, the point is
probably moot anyway.)

> Doing 'man 3 ldap_search' reveals that the openldap client API
> itself does not support callbacks, so the OCaml module can't either.

I'm not sure that if the openldap API supported callbacks, they could
easily be "imported" in OCaml anyway. I have very, very little
experience in interfacing OCaml with C, but I sense a problem with the
fact that an OCaml function is not a C function. Probably the bindings
can "on the fly" do boxing/unboxing, but this incurs a heavy
performance penalty (when compared to the cost of a function call in
OCaml).

> Callback snippet from perldoc Net::LDAP

>   Most of the above commands accept a callback option. 
>   This option should be a reference to a subroutine. 
>   This subroutine will be called for each packet
>   received from the server as a response to the request sent.

I don't know enough about LDAP to know what is meant by packet. If, in
the case of a search, packet means result, then in OCaml, you can use
map/fold_left to achieve this effect, as I said above.

>>> Did you have a look at http://pleac.sourceforge.net?

>> Not yet. 5 minutes later: Ugh. To contribute, I have to read and
>> understand the Perl code first, thus teach myself Perl? Ugh. Big
>> entry barrier. Would you be willing to translate from Perl to
>> English for me?

> You should ask this on the Pleac mailinglist, indeed a programming
> language neutral 'specification' of the cookbook would be a nice
> thing.

If it can be achieved at all... And you would get into hot waters with
O'Reilly, because you would be "obviously" writing the specification
from their specification, thus creating a derived works from
theirs. You just have to wait 28 years, for them to abandon
copyright... (They decided to voluntarily limit their copyright rights
to 28 years after publication.)

> However, the Pleac headers above each section are quite clear on
> what the problem domain is, IMO.

Well yes, but the "subsection" headers are sometimes very cryptic,
sometimes vague:

Program: Sorting Your Mail
Program: Binary Trees
Randomizing All Lines
Reading Configuration Files

 Yeah, what *exactly* should I be doing here?

Program: hopdelta
Detecting Return Context
Program: symirror
Program: lst
Testing a File for Trustworthiness
Soundex Matching

 Absolutely no clue what is meant.

> Hmm, I just saw this last line in the 'file access' section:
> END { &genocide }

?

>> "Creating Persistent Private Variables" maybe would be a valid
>> trick.

> Serialization/de-serialization is also needed for more complex data
> structures.

I think you call Serialization/de-serialization what I call
Marshalling. You mean writing as a stream of bytes that can be put in
a file, transferred over network, etc and re-read again and you have
the same data?

Anyway, I think I'll pick up the low-hanging fruit when I get some
time.

>>> PS: No need to CC me, I'm subscribed to this list.

>> What about setting a Mail-Followup-To, then? Oh, and the first msg
>> wasn't to the list CC to you, it was to YOU, CC the
>> list. Difference.

> I know, this was advise to anybody replying to my message not to CC
> me.

Use Mail-Followup-To. Just add "subscribe people@xxxxxxxxxx" to your
.muttrc and all people using a reasonable MUA won't CC you any more
messages to people@xxxxxxxxxx.


Gerelateerd:


[ Date Index] [ Thread Index]