On Thu, Dec 27, 2012 at 12:45 PM, Gracjan Olbiński wrote:
Hi!
I wonder to know whether the package proposed by Michael has any chance to
be a part of go lang library and the implementation of its will be
continued?
Hi!
I wonder to know whether the package proposed by Michael has any chance to
be a part of go lang library and the implementation of its will be
continued?
"go get" mechanism is intended to make it very easy to install third-party
packages. Something like ldap seems unlikely to be included unless it is a
dependency of another package (which is the reason that some crypto is in
the stdlib and some is in go.crypto). I can't speak for API additions to
the asn1 functionality; that would probably have to be run by golang-dev,
but I suspect that unless it's needed by the standard library the feeling
would be that it won't get enough attention to be in the stdlib.
Br,
Gracjan
W dniu piątek, 18 lutego 2011 07:49:29 UTC+1 użytkownik Michael Mitton
napisał:
--Gracjan
W dniu piątek, 18 lutego 2011 07:49:29 UTC+1 użytkownik Michael Mitton
napisał:
Is anyone thinking about this? I've been working on my code in the
meanwhile, and put it up on github for anyone interested for now.
github.com/mmitton/asn1-ber
github.com/mmitton/ldap
The ldap library is coming along nicely. The asn1-ber library is still
very limited and missing many types. I need to dive in to the spec and
work on it some more.
Thank you.
-Michael
meanwhile, and put it up on github for anyone interested for now.
github.com/mmitton/asn1-ber
github.com/mmitton/ldap
The ldap library is coming along nicely. The asn1-ber library is still
very limited and missing many types. I need to dive in to the spec and
work on it some more.
Thank you.
-Michael
On Tue, Feb 15, 2011 at 8:03 PM, Michael Mitton wrote:
LDAP uses a lot of tags which are combinations such as
Universal - Constructed - [Magic LDAP code]
or
Application - Constructed - [Magic LDAP code]
which may or may not contain data as part of the tag or also may contain
children tags.
One key needed feature is the choice tag. I don't believe (and I could
be wrong) asn1 has any way of encoding or decoding this since it uses
reflection and I don't know that go variables support such a concept. The
data contained in the tag could all be of one type, or different types.
I went a different route and do not use reflection to encode / decode
tags. I instead allow the calling code to be very specific in what they
want to encode / decode. After writing it once, I plan on rewriting it
since I now have a better grasp on go as a language, and I want to fill in
all the missing types (I only support a few at this point in order to get
LDAP working) and better error handling.
Knowing this is _not_ how I would like to submit it at all, but wanting
to get some initial feedback, I am attaching the code I have so far along
with a test application.
Let me know what you think.
-Michael
--LDAP uses a lot of tags which are combinations such as
Universal - Constructed - [Magic LDAP code]
or
Application - Constructed - [Magic LDAP code]
which may or may not contain data as part of the tag or also may contain
children tags.
One key needed feature is the choice tag. I don't believe (and I could
be wrong) asn1 has any way of encoding or decoding this since it uses
reflection and I don't know that go variables support such a concept. The
data contained in the tag could all be of one type, or different types.
I went a different route and do not use reflection to encode / decode
tags. I instead allow the calling code to be very specific in what they
want to encode / decode. After writing it once, I plan on rewriting it
since I now have a better grasp on go as a language, and I want to fill in
all the missing types (I only support a few at this point in order to get
LDAP working) and better error handling.
Knowing this is _not_ how I would like to submit it at all, but wanting
to get some initial feedback, I am attaching the code I have so far along
with a test application.
Let me know what you think.
-Michael
On Tue, Feb 15, 2011 at 4:22 PM, agl wrote:
of the code in any case. I still wonder if it would have been better
to use code generation.
If the changes to asn.1 to parse BER are reasonably small then I'd
likely to ok with updating asn1. Can you elaborate on some of the
constructs which asn1 doesn't currently handle?
Cheers
AGL
On Feb 15, 11:22 am, Michael Mitton wrote:
I am working on a project which required LDAP lookups. Since there
doesn't seem to be any support for LDAP in go at this point, I thought
I would open up the RFC and take a stab at it. I also thought I got
lucky when I saw the asn1 package, but that is DER only, so I also
ended up working on basic BER encoding/decoding. It is much more
generic than the DER marshal/unmarshal model since some pretty odd
constructs not only seem possible in BER encoding, but are actively
used in LDAP.
asn1 is, indeed, DER only and I wouldn't say that I'm especially proudI am working on a project which required LDAP lookups. Since there
doesn't seem to be any support for LDAP in go at this point, I thought
I would open up the RFC and take a stab at it. I also thought I got
lucky when I saw the asn1 package, but that is DER only, so I also
ended up working on basic BER encoding/decoding. It is much more
generic than the DER marshal/unmarshal model since some pretty odd
constructs not only seem possible in BER encoding, but are actively
used in LDAP.
of the code in any case. I still wonder if it would have been better
to use code generation.
If the changes to asn.1 to parse BER are reasonably small then I'd
likely to ok with updating asn1. Can you elaborate on some of the
constructs which asn1 doesn't currently handle?
Cheers
AGL
