Re: [9fans] More 'Sam I am'

Re: [9fans] More 'Sam I am'

[quanstro]

isn't this the "i don't trust new software" argument resurrected?
let's all install V7 from mag tape on our pdp-11s. ;-)

sorry. i couldn't resist.

- erik

On Fri Feb 10 16:54:45 CST 2006, lucio@proxima.alt.za wrote:
> > Would you pick
> > XML or ASN.1 if those were the only two options?  If the pointy-haired
> > powers that be are mandating one or the other and, ``neither'' isn't in
> > the range of possible solutions?
> 
> 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.
> 
> ++L
> 

Re: [9fans] More 'Sam I am'

[jmk]

Many years ago now, a good friend of mine remarked that
if we actually made all those whining about the state of things
now compared to the "good old days" go back to using v7 Unix,
they would quickly realise that times had actually moved
forward and there were things they were used to that it didn't
have and that they really needed. I used v[567] and I've
ported v7, and I wouldn't go back. From what I understand,
Plan 9 was an attempt to build on that by saying "this got
us so far, but times are changing and it won't cut it with
networks, bitmapped displays, SMP etc, we need a better base".
That was a long time ago and no one has, to my limited
non- computer science knowledge, attempted anything similar,
they're all still working on copying 30 year old technology.

I don't have an iPod, my mobile phone is 5 years old and I
turn it on about 4 hours a week and there are many things
about the 21st century that make me grumpy. But you can't go
back. You should, however, be careful about how how you
go forward.

--jim

On Fri Feb 10 19:12:00 EST 2006, quanstro@quanstro.net wrote:
> isn't this the "i don't trust new software" argument resurrected?
> let's all install V7 from mag tape on our pdp-11s. ;-)
> 
> sorry. i couldn't resist.
> 
> - erik
> 
> On Fri Feb 10 16:54:45 CST 2006, lucio@proxima.alt.za wrote:
> > > Would you pick
> > > XML or ASN.1 if those were the only two options?  If the pointy-haired
> > > powers that be are mandating one or the other and, ``neither'' isn't in
> > > the range of possible solutions?
> > 
> > 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.
> > 
> > ++L
> > 

[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.

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

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

[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

[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

[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

[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

[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

[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

[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

ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> isn't this the "i don't trust new software" argument resurrected?
> let's all install V7 from mag tape on our pdp-11s. ;-)
> 
> sorry. i couldn't resist.

You're welcome, but I think you're off the mark.  X.680 is less than
100 pages and is written in that peculiar jargon that CCITT/ITU-T have
evolved to make sure that the real niggly faults are well hidden where
they can only be discovered in the most painful fashion.

Perhaps it is seriously flawed, but I have only a single paper by Carl
Ellison entitled ASN.1 Misuse (September 15, 1995) to back that
argument:

	"The ASN.1 standard (Abstract Syntax Notation 1) is
	proliferating, in spite of cries of anguish by computer
	professionals who are faced with implementing to those
	standards.  The standard is flawed.  Some of those flaws come
	from its complexity and ambiguity - a product most likely of
	having started down the wrong path and been subject to
	corrections by various interested parties along the way.  It
	has acquired various warts and is apparently the result of a
	committee effort.  Other flaws come from its misuse, and those
	are the one addressed in this paper."

I note I'm missing pages 5 to 6 (of 6 :-).  Thing is, XML is not 100
pages long, is nothing like less "complex or ambiguous" and is still
work in progress.  How much can one add to such a beast before its
camel back breaks?

And my question remains: "What is a better option for the conveying of
platform-independent data than ASN.1 or XML?"

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[geoff]

> "What is a better option for the conveying of platform-independent
> data than ASN.1 or XML?"

A somewhat-flippant answer would be text strings and numbers expressed
as strings.  But what ASN.1 (or BER) and XML seem to be trying to do
is to permit the export and later import of essentially arbitrary C
structs in a manner that will be portable across processor
architectures.  /sys/src/libsec/port/x509.c seems to be mostly
concerned with ASN1 and it's 2,559 lines long, and that's short
compared with the openssl ASN1 routines, which total 16,071 lines in
my copy.  So why not /lib/ndb format: textual attribute=value pairs
with grouping?

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> So why not /lib/ndb format: textual attribute=value pairs
> with grouping?

Because (a) they are language/alphabet specific and (b) they are
inefficient.

Before you jump down my throat, I am aware that the inefficiencies
smack of premature optimisation, but in ASN.1 days they were mere
failures of vision.  And I do maintain that saving processor cycles
and storage is not a futile quest.  The corollary to Moore's Law is
"Software bloat exceeds any gains in processor performance even before
such gains can be exploited".

It also strikes me as remarkable that you'd think ASN.1 is intended to
represent C structures.  I would think the intent was to be a message
format on the wire and the internal representation was left as a
matter of implementation.  The latter, of course, is where it all fell
apart because (a) there were issues that could not be finalised
without conflict and (b) there were mistakes that were only discovered
once different implementations could not interoperate.

In the latter case, I have to concede that the IETF is better geared
for the laying down of standards.  Skip is right in that standards
ought not to be accepted until there has been an implementation, but
of course that sword has two edges, too.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[geoff]

Hmm, the old language-specific argument.  The usual solution to this
is to use a binary encoding, the theory being that by avoiding words,
you avoid chauvinism.  I'd still rather have a textual format, even if
the attribute names have to be translated for speakers of other
languages (they'd have to translate a binary encoding into their own
language anyway).  If we wanted to inconvenience everyone equally, the
attribute names could be gibberish.

I'm not convinced that the slight inefficiency matters, particular for
a message format.  We do build indices in /lib/ndb to speed searches,
but that's for searching, not just encoding for transmission.  If
you're thinking of binary-decimal conversion overheads, one could
insist upon using octal representation (as tar does), which can be
converted more quickly than decimal, though that does make it a little
less human-friendly.

There has to be mapping between message format and something like a C
struct (some internal representation).  ASN.1 attempts to describe
both, as I understand it, to facilitate conversion between the two.

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> If we wanted to inconvenience everyone equally, the
> attribute names could be gibberish.
> 
Or binary.  Even your argument goes full circle.  And because we're
talking about information on the wire, why not stick to what the end
points process best?

Not that ASN.1 should be defended, but your argument needs its holes
poked :-)

> If
> you're thinking of binary-decimal conversion overheads, one could
> insist upon using octal representation (as tar does), which can be
> converted more quickly than decimal, though that does make it a little
> less human-friendly.
> 
The human-friendly bit is a chimera, It's data on the wire, it was
never the intent of CCITT (I presume) to treat it as anything else.
Much as you can't detect the magnetic properties of core to decide
what is in memory, you need some sort of translator to inspect the
data on the wire.  In CCITT terms, that isn't a problem as cost was
never a consideration when investing in projects with 30- to 50-year
life spans.  It's the urgency of new technology that forces costs all
the way down and deprives R&D departments of multi-digit budgets.

> There has to be mapping between message format and something like a C
> struct (some internal representation).  ASN.1 attempts to describe
> both, as I understand it, to facilitate conversion between the two.

I'm not an ASN.1 guru, never will be.  But I think ASN.1 is intended
to be the permanent representation, with ephemeral internal formats as
dictated by processing.  I'm not sure where in the ITU-T
recommendations I'd have to look to contradict you, however.

It is perfectly possible for the ITU-T committee to have decided to
intrude where they did not belong.  They certainly mirrored the
computer architectures of the time, with various predefined integer
sizes as well as a variable length alternative, so they are guilty of
parochial thinking.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Steve Simon]

> So why not /lib/ndb format: textual attribute=value pairs
> with grouping?

Vote 1 for Geoff.

Seriously I tried this for a project, but got loads of flak for not
using The Standard (XML) so when I "threw one away" last year I reworked
the system using XML.

To be honest the pain was short lived - writing the parser, and since
then I don't see much difference. There are some of XMLs stranger rules
and all those [<>/] which look a mess to my C trained eyes but I try
not to look too often.

(Before anyone jumps doen my throat I wrote a parser because I am on a
small embedded system)

-Steve

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Bruce Ellis]

I implemented both in ozinferno.  ASN is almost ludicrous.
XML was remarkably easy but ruthless.  anyhow my XML
parser does parse the XML spec (written in XML) and i'm
yet to find a commercial product that does.

brucee

On 2/11/06, Steve Simon <steve@quintile.net> wrote:
> > So why not /lib/ndb format: textual attribute=value pairs
> > with grouping?
>
> Vote 1 for Geoff.
>
> Seriously I tried this for a project, but got loads of flak for not
> using The Standard (XML) so when I "threw one away" last year I reworked
> the system using XML.
>
> To be honest the pain was short lived - writing the parser, and since
> then I don't see much difference. There are some of XMLs stranger rules
> and all those [<>/] which look a mess to my C trained eyes but I try
> not to look too often.
>
> (Before anyone jumps doen my throat I wrote a parser because I am on a
> small embedded system)
>
> -Steve
>

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Skip Tavakkolian]

i think any committee that comes up with a proposed standard should
individually be responsible for implementing it.  note that this would
work for large or small efforts.  if the committee is able to
implement it and it works, then it would be adopted.

specific to the question, i like the S-expression approach I've not
used it for anything so my advice is as good as the random committee
member.

> And my question remains: "What is a better option for the conveying of
> platform-independent data than ASN.1 or XML?"

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[geoff]

> i think any committee that comes up with a proposed standard should
> individually be responsible for implementing it.

That's not how PTTs do things!  How do you think they came up with
crap like OSI (X.400, X.500)?  Sheesh, get real, kid!  ☺

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> That's not how PTTs do things!  How do you think they came up with
> crap like OSI (X.400, X.500)?  Sheesh, get real, kid!  ☺

Come, come, Geoff!  They did precisely as they needed to.  It probably
has a lot in common with the urethra doubling back into the prostrate
gland.  Has anyone produced a better mouse trap yet?  I note with
horror that internationalisation is creeping into LDAP.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Skip Tavakkolian]

>> i think any committee that comes up with a proposed standard should
>> individually be responsible for implementing it.
> 
> That's not how PTTs do things!  How do you think they came up with
> crap like OSI (X.400, X.500)?  Sheesh, get real, kid!  ☺

what i meant to say was "if i was philosopher-king in charge of the world i
would make any committee ..."

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.
> 
>