Re: [9fans] asn.1 alternatives

Re: [9fans] asn.1 alternatives

[quanstro]

i've done this before. (but i wasn't responsible for the exchange half.)
it actually worked better than exchange-only because sendmail is
(was) much better at dealing with smtp mail.

- erik

On Sat Feb 11 10:24:28 CST 2006, lucio@proxima.alt.za wrote:

> than usual because I'll insist in front-ending Exchange with the
> existing Sendmail installation, modified in haste to deliver to
> Exchange instead of the local mailboxes.  All sorts of extremely fancy
> features of Exchange will be used and the reliability of the existing
> system will soon will be forgotten.
> 
> 

Re: [9fans] asn.1 alternatives

[Harri Haataja]

On Sat, Feb 11, 2006 at 02:29:19PM +0000, Charles Forsyth wrote:
> when i need to represent more than simple text or values, or attribute
> value pairs, which isn't all that often, more and more i use Rivest
> S-expressions, as i did on wednesday.
> they are unambiguous (unlike both ASN.1 and XML), easy to read and
> write, that can represent binary directly where that's appropriate,
> with an `advanced textual form' (like it!) that people can read
> without suffering eye strain, but with a well-defined canonical form
> (always helpful when comparing or signing things).

Sexprs would get my humble vote as well.

BTW, re XML, there's also SXML that may or may not be interesting.
http://okmij.org/ftp/Scheme/SXML.html

-- 
The memory management on the PowerPC can be used to frighten small children.
		-- Linus Torvalds

Re: [9fans] asn.1 alternatives

[Brantley Coile]

> I think, perhaps, that this is less true than it once was.  In particular,
> they need to answer to marketting and ensure that the product is sufficiently
> buzzword compliant.  But my point in bringing up the managerial team in the
> first place was just to demonstrate that sometimes the person doing the
> implementation doesn't *really* have all that much control over the choices
> made for the implementation.  An extreme example would be, say, if I were

I find the most pressure on technical design to be one's peers.
Entrenched technology carries a lot of weight.  Pressure from
co-workers to use the popular technology is also strong.  A lot of it
is just fashion; a lot is the `teach what industry wants, use what
universities teach' cycle.

Just look for every place you can strech things a bit.  If you're
talking to a SNMP client, you've got to use BER.  If a web site is
going to force XML at you, just do it.  But when possible, from my
experience, just use text.

ASN1 reminds me of something that happened a few years ago.  I ported
V7 to an embedded application where my co-workers were developing the
rest of the system on Sun4s.  I warned them that my port was going to
be 32 bit and that structure members would align to 4 bytes, not 2, as
SunOS did in those days.  They said that wasn't a problem, since they
were marshalling the data into and out of the messages.  Turns out
that their marshalling code was full of structure alignment
assumptions and they spend two weeks geting the library to work.

Re: [9fans] asn.1 alternatives

[Marina Brown]

lucio@proxima.alt.za wrote:

>>also, in my experience, managers (pointy-head or not) are rarely overly
>>caught up by the technical details.  they just want such-and-such a problem to go away.
>>they usually don't really care how you do it, especially if it works well
>>and they never ever have to cut short a trip to the golf course because of it.
>>    
>>
>
>I don't share your luck and I think few do, although this forum may be
>more fortunate in that respect.  I am heading to Cape Town tomorrow
>morning to install MS Exchange in what will probably still be a NetBSD
>shop for a year or so.  Me, when I have no idea what Exchange actually
>look like!
>
>This is what comes of bucking the trend successfully.  IT management
>there believe it will cost them less to entrust the installation to me
>than to bring in an MCSE (by whatever the current label may be) that
>will install herself permanently behind the Exchange keyboard at a
>formidable monthly salary.  What will in fact happen, sadly, is that
>I'll be blamed for all the things that will go wrong with MS Exchange,
>irrespective of the real responsibility, more things will go wrong
>than usual because I'll insist in front-ending Exchange with the
>existing Sendmail installation, modified in haste to deliver to
>Exchange instead of the local mailboxes.  All sorts of extremely fancy
>features of Exchange will be used and the reliability of the existing
>system will soon will be forgotten.
>
>  
>
Reminds me of last weekend - i got a paniced call from one of the sales
execs - one with a clue - to get him OFF the exchange server because of
the problems. Now he is happy to have his mail forwarded to a linux 
virtserver
where he uses procmail and pine. I am ever so greatfull i am not responsible
for the exchange. I warned them against it and they went with a hosted 
solution
which gives people 150MB of mailbox space.... About the volume i dispose of
after a long weekend.

Good Luck...

-- Marina Brown

Re: [9fans] asn.1 alternatives

[Skip Tavakkolian]

i wonder if this is an entropy  phenomenon.  when an ABSTRACT
notation is made CONCRETE, something has to give.  it is as if instead
of just translating a message in English to one in French, one sent
a polyglot along with the message.

>>>> > What are the alternatives?  My pick is ASN.1, any time.
> 
> Ha.  I'm working on a UMTS base station (another, interesting tale
> of hard real time in Plan 9) and we're using an ASN.1 compiler that
> typically takes 30-bytes ASN.1 packed messages and decompresses
> them into 5 megabyte (yes, MEGA byte) C structs.  Amazing.

Re: [9fans] asn.1 alternatives

[Charles Forsyth]

> made for the implementation.  An extreme example would be, say, if I were
> writing a Windows application.  I probably don't have much ability to write
> it for another system (Unix, Plan 9, whatever) instead because I'd prefer
> that.

that isn't quite what i was suggesting (it was fairly carefully worded): in such a case you
probably wouldn't have made `a problem go away', but rather introduced a new one
because your solution was quite possibly fine but for a different environment.

as a small concrete example, some of our grid users run existing Windows
binaries for which source is unavailable, so the application does need to
run on Windows (or perhaps a close emulation of it), and trying to
convert it (say) to Limbo isn't particularly helpful; on the other hand,
that still doesn't stop us using Inferno to build the grid infrastructure well
and pleasantly (and without using XML or web services anywhere, as it happens),
within the Windows environment.

i wasn't suggesting one had carte blanche, just that it's often possible to
find more freedom than one might initially expect in providing the solution;
i also pointed out that anything off-beat might need to work really well
to keep them happy [on the golf course] (but then, if it doesn't, why use it?)

one point i didn't make, but ought to have done, is that it can be a little
trickier when one is in competition for work, but even there it can be done.

Re: [9fans] asn.1 alternatives

[Dan Cross]

On Sat, Feb 11, 2006 at 02:29:19PM +0000, Charles Forsyth wrote:
> also, in my experience, managers (pointy-head or not) are rarely overly
> caught up by the technical details.  they just want such-and-such a problem
> to go away.  they usually don't really care how you do it, especially if it
> works well and they never ever have to cut short a trip to the golf course
> because of it.

I think, perhaps, that this is less true than it once was.  In particular,
they need to answer to marketting and ensure that the product is sufficiently
buzzword compliant.  But my point in bringing up the managerial team in the
first place was just to demonstrate that sometimes the person doing the
implementation doesn't *really* have all that much control over the choices
made for the implementation.  An extreme example would be, say, if I were
writing a Windows application.  I probably don't have much ability to write
it for another system (Unix, Plan 9, whatever) instead because I'd prefer
that.

As for ASN.1 alternatives....  When you have a choice, I would agree that
S expressions are compelling.  Another option is YAML, which is becoming
popular in the scripting language world, and is fairly reasonable, even for
representing complex hierarchical objects.

	- Dan C.

Re: [9fans] asn.1 alternatives

[lucio]

> and by the insistence of the comiler to code anything that
> has a known maximum length by a static array of that length.

I've never seen any of these mythical monsters, what do they really
look like?  Looking at the innumerable implementations of ASN.1
libraries, one is tempted to believe that enough effort has been
deployed in that direction.  Does any of the Open Source stuff
(Heimdal, OpenLDAP, OpenSSL, rdesktop, to name but a few) actually
ever re-use someone else's ASN.1 libraries?

++L

Re: [9fans] asn.1 alternatives

[lucio]

> also, in my experience, managers (pointy-head or not) are rarely overly
> caught up by the technical details.  they just want such-and-such a problem to go away.
> they usually don't really care how you do it, especially if it works well
> and they never ever have to cut short a trip to the golf course because of it.

I don't share your luck and I think few do, although this forum may be
more fortunate in that respect.  I am heading to Cape Town tomorrow
morning to install MS Exchange in what will probably still be a NetBSD
shop for a year or so.  Me, when I have no idea what Exchange actually
look like!

This is what comes of bucking the trend successfully.  IT management
there believe it will cost them less to entrust the installation to me
than to bring in an MCSE (by whatever the current label may be) that
will install herself permanently behind the Exchange keyboard at a
formidable monthly salary.  What will in fact happen, sadly, is that
I'll be blamed for all the things that will go wrong with MS Exchange,
irrespective of the real responsibility, more things will go wrong
than usual because I'll insist in front-ending Exchange with the
existing Sendmail installation, modified in haste to deliver to
Exchange instead of the local mailboxes.  All sorts of extremely fancy
features of Exchange will be used and the reliability of the existing
system will soon will be forgotten.

My shoulders aren't wide enough to carry that load, but I can't afford
to charge them what would be market related fees for my experience
because it is not what they and their colleagues perceive to be the
mainstream, so I'll have to sneak away from under their system very
slowly and very surreptitiously as soon as I can find an alternative
position.  They will not, of course, discuss this, as they do not want
to be encumbered with the necessary and unpleasant reality.

Sigh!

++L

PS: If you have a broad-spectrum position at Vitanuova that involves
vision rather than productivity, I'm your man :-)

Re: [9fans] asn.1 alternatives

[Sape Mullender]

>>> > What are the alternatives?  My pick is ASN.1, any time.

Ha.  I'm working on a UMTS base station (another, interesting tale
of hard real time in Plan 9) and we're using an ASN.1 compiler that
typically takes 30-bytes ASN.1 packed messages and decompresses
them into 5 megabyte (yes, MEGA byte) C structs.  Amazing.
In the defense of ASN.1 I must say that this is not so much caused by
ASN.1 as by the incredible amount of configurational possibilities in
UMTS connections (almost none of which are or will be  implemented
by anybody), and by the insistence of the comiler to code anything that
has a known maximum length by a static array of that length.

	Sape

[9fans] asn.1 alternatives

[Charles Forsyth]

>> > What are the alternatives?  My pick is ASN.1, any time.  You can call
>> > the ITU-T by as many ugly names as you like, but their standards are
>> > considerably more firm than more recent publications.

when i need to represent more than simple text or values, or attribute value pairs, which isn't all that often,
more and more i use Rivest S-expressions, as i did on wednesday.
they are unambiguous (unlike both ASN.1 and XML),
easy to read and write, that can represent binary directly where that's appropriate,
with an `advanced textual form' (like it!) that people can read without suffering eye strain,
but with a well-defined canonical form (always helpful when comparing or signing things).

i keep intending to try armstrong's ubf, but haven't, yet.
it's perhaps more in the XML-RPC or ASN.1 realm.
it has some good ideas, anyhow.

simple text or values, or attribute value pairs are often adequate,
require little code to read or write, and are often more efficient when all
costs are taken into account.   if you're lacking a `standard' for something
you'd like to use, and you need that extra justification,
just write an RFC, and then say ``i'm following an existing RFC''.

on the other hand, if you're trying to talk certain existing protocols, you need some
quantity of ASN.1; if you're trying to interpret certain existing data, you might need some XML.
just remember, though, that no one needs `Web Services', the os/360 for
the 21st century, and the upas tree of distributed systems.
whenever it comes up, just hack round it, and even that is more than it deserves.

also, in my experience, managers (pointy-head or not) are rarely overly
caught up by the technical details.  they just want such-and-such a problem to go away.
they usually don't really care how you do it, especially if it works well
and they never ever have to cut short a trip to the golf course because of it.