Stuff that breaks when you move it

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Stuff that breaks when you move it

Joe Armstrong-2
There's two kinds of stuff:

    A) Stuff which doesn't break when you move it
    B) Stuff which breaks when you move it

Type A includes:
    zip files,  PDF files, jpg files, mp3 files, ...


Type B includes:
     Erlang, HTML files, DRM protected files, erlang beam files, ...


A good general principle is:

    P-1 - "Stuff should not break if you move it to a new directory"

A is good B is bad.

Experiment:

    # cd /usr/local/lib
    # mv erlang globble
    # globble/bin/erl
    exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found

Thus Erlang is in B.

But it doesn't have to be so - this is a bug not a feature

Note: 1) This problem (stuff breaking when you move it) is
a particular pain when you have to make something work
that depends upon several different components and each one
individually breaks when you move it.

2) Sometimes stuff cannot be moved to where the author wanted
you to move it to. So if you have not got admin rights
you *cannot* move your program to /bin (or whatever)

So lets add:

     P-2: It should be possible to move stuff to *any*
          directory in the file system to which you have write access
          without breaking it.

And while we're on the subject:

     P-3: We should be able to *remove* stuff without breaking
     other stuff that is not dependent upon the stuff we have removed.

 And

     P-4: If we add stuff to the system and then remove it we should put
     the system back to the state it was in before we added the
     stuff that we removed. (Possibly we might change the state of the
     system log to say that we have added and removed something,
     but nothing else should happen)

Very little software obeys principles P-1 to P-4.

This is bad.

Fix it.

Cheers

/Joe

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Bengt Kleberg
Greetings,

One solution is Plan9 (http://plan9.bell-labs.com/plan9/).


bengt

On Mon, 2009-08-03 at 15:04 +0200, Joe Armstrong wrote:

> There's two kinds of stuff:
>
>     A) Stuff which doesn't break when you move it
>     B) Stuff which breaks when you move it
>
> Type A includes:
>     zip files,  PDF files, jpg files, mp3 files, ...
>
>
> Type B includes:
>      Erlang, HTML files, DRM protected files, erlang beam files, ...
>
>
> A good general principle is:
>
>     P-1 - "Stuff should not break if you move it to a new directory"
>
> A is good B is bad.
>
> Experiment:
>
>     # cd /usr/local/lib
>     # mv erlang globble
>     # globble/bin/erl
>     exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found
>
> Thus Erlang is in B.
>
> But it doesn't have to be so - this is a bug not a feature
>
> Note: 1) This problem (stuff breaking when you move it) is
> a particular pain when you have to make something work
> that depends upon several different components and each one
> individually breaks when you move it.
>
> 2) Sometimes stuff cannot be moved to where the author wanted
> you to move it to. So if you have not got admin rights
> you *cannot* move your program to /bin (or whatever)
>
> So lets add:
>
>      P-2: It should be possible to move stuff to *any*
>           directory in the file system to which you have write access
>           without breaking it.
>
> And while we're on the subject:
>
>      P-3: We should be able to *remove* stuff without breaking
>      other stuff that is not dependent upon the stuff we have removed.
>
>  And
>
>      P-4: If we add stuff to the system and then remove it we should put
>      the system back to the state it was in before we added the
>      stuff that we removed. (Possibly we might change the state of the
>      system log to say that we have added and removed something,
>      but nothing else should happen)
>
> Very little software obeys principles P-1 to P-4.
>
> This is bad.
>
> Fix it.
>
> Cheers
>
> /Joe
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Witold Baryluk
In reply to this post by Joe Armstrong-2
Dnia 2009-08-03, pon o godzinie 15:04 +0200, Joe Armstrong pisze:
> There's two kinds of stuff:
>
>     A) Stuff which doesn't break when you move it
>     B) Stuff which breaks when you move it

> Thus Erlang is in B.
>
> But it doesn't have to be so - this is a bug not a feature
>
> Note: 1) This problem (stuff breaking when you move it) is
> a particular pain when you have to make something work
> that depends upon several different components and each one
> individually breaks when you move it.
>
> 2) Sometimes stuff cannot be moved to where the author wanted
> you to move it to. So if you have not got admin rights
> you *cannot* move your program to /bin (or whatever)
>
> So lets add:
>
>      P-2: It should be possible to move stuff to *any*
>           directory in the file system to which you have write access
>           without breaking it.
>
> And while we're on the subject:
>
>      P-3: We should be able to *remove* stuff without breaking
>      other stuff that is not dependent upon the stuff we have removed.
>
>  And
>
>      P-4: If we add stuff to the system and then remove it we should put
>      the system back to the state it was in before we added the
>      stuff that we removed. (Possibly we might change the state of the
>      system log to say that we have added and removed something,
>      but nothing else should happen)
>
> Very little software obeys principles P-1 to P-4.
>
> This is bad.
>
> Fix it.
I think that Debian packaging system and policy enforces to obey
P3 and P4.

About P1 and P2, it is about parametrization of paths mainly in
dependent stuff,
sometimes it is good (many versions can coexist), sometimes bad (lots of
additional configuration needed by user, or special detection
procedures, with some convention for default paths, and when many
versions exists which to remove on upgrades). Anyway most tools,
should be beware about self location, this is for example,
why many tools/scripts uses $0 aka argv[0] to refer to itself, not
necessary default name/path given by author. Similarly with paths.

LHS can be helpful here also, but this standard is mostly about
system locations. I don't know if it is easy to maintain similar
structure in users' home directory.



--
Witold Baryluk <[hidden email]>

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Dave Smith-10
In reply to this post by Joe Armstrong-2
On Mon, Aug 3, 2009 at 7:04 AM, Joe Armstrong<[hidden email]> wrote:

> Experiment:
>
>    # cd /usr/local/lib
>    # mv erlang globble
>    # globble/bin/erl
>    exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found
>
> Thus Erlang is in B.
>
> But it doesn't have to be so - this is a bug not a feature

+1.

I've never understood why the Erlang distribution embeds absolute
paths into all the executables generated. It seems to me that
requiring something akin to the JAVA_HOME environment variable would
be a better solution which ensures portability across directory
structures and machines.

My $0.02 :)

D.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Robert Raschke
In reply to this post by Joe Armstrong-2
I agree wholeheartedly, it would make so many things so much easier if you
can move stuff around without it breaking.

Interestingly enough, though, in terms of applications that are installed on
machines in an environment managed by an IT department, you very quickly
bounce against the "we need to know what's installed" problem. In a lot of
cases this actually means "we do not want to allow just random things to
run".

In environments like that, having something that'll only work in exactly the
location it was (properly) installed, is a "good" thing. I don't think it is
necessarily the right way to solve that problem. But it's the currently
established one :-(

Robby
Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Masklinn
In reply to this post by Joe Armstrong-2
On 3 Aug 2009, at 15:04 , Joe Armstrong wrote:
> Type B includes:
>     Erlang, HTML files, DRM protected files, erlang beam files, ...
>
I'm pretty sure HTML files do *not* break when you move them.

They might lose their references to CSS, JS or image files linked  
stupidly (e.g. absolutely) but the HTML will always work. Now whether  
the HTML was correctly authored is another can o' worms.

-m

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Joe Armstrong-2
On Mon, Aug 3, 2009 at 5:47 PM, Masklinn<[hidden email]> wrote:

> On 3 Aug 2009, at 15:04 , Joe Armstrong wrote:
>>
>> Type B includes:
>>    Erlang, HTML files, DRM protected files, erlang beam files, ...
>>
> I'm pretty sure HTML files do *not* break when you move them.
>
> They might lose their references to CSS, JS or image files linked stupidly
> (e.g. absolutely) but the HTML will always work. Now whether the HTML was
> correctly authored is another can o' worms.

I consider them broken in the sense that they will not display the same
thing if moved - I'm comparing them with PDF files which do  not break
when moved. Now you can embed js, css and even jpgs into the html
so that they do work if moved but nobody does this.

/Joe


>
> -m
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

kamiseq
ok, but swf, jars, pdfs, avi... they create some "system" that everything
what is needed to run is inside.
so when you look at your project as on the system that have everything to
run inside it, then moving things is just breaking that system and the same
for pdf, it will not work if you download only 60% of it.. (or maybe I read
posts to quickly and I dont follow you at all)

anyway I would like to see where that conversation will end :)

pozdrawiam
Paweł Kamiński

[hidden email]
[hidden email]
______________________
Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Dave Pawson-2
In reply to this post by Joe Armstrong-2
2009/8/3 Joe Armstrong <[hidden email]>:

> I consider them broken in the sense that they will not display the same
> thing if moved - I'm comparing them with PDF files which do  not break
> when moved. Now you can embed js, css and even jpgs into the html
> so that they do work if moved but nobody does this.

Hopefully.
And for good reason Joe.
The 'cascade' provides for users to override CSS for such
as accessibility reasons.

Embedded CSS (and js for that matter) should be history by now.


regards






--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Christian S-2
In reply to this post by Joe Armstrong-2
On Mon, Aug 3, 2009 at 15:04, Joe Armstrong<[hidden email]> wrote:
> There's two kinds of stuff:
>
>    A) Stuff which doesn't break when you move it
>    B) Stuff which breaks when you move it

I'm not sure if you were just talking about general design but this example:

> Experiment:
>
>    # cd /usr/local/lib
>    # mv erlang globble
>    # globble/bin/erl
>    exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found

This is surely just about the paths inside the script 'erl' itself.
The ROOTDIR variable in there looks suspicious indeed.

I actually quite like that erl stores the installation directory in
itself. I prefer it over java's JAVA_HOME environment variable. If I
want to use a specific java version i have installed I need to set
JAVA_HOME correctly, AND start the right java binary. In erlang I
point out what I want and that is what I get.

Since argv[0] / $0 is unreliable for finding the installation dir, I
think Erlang does the pragmatic best way for being insensitive to what
its installation dir is.

Also, about HTML, what some (you?) perceive as a disadvantage is
someone else's advantage. If every HTML document would include the
pictures, scripts and css, then you would have to load all that even
if those parts were the same.

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Joe Armstrong-2
On Mon, Aug 3, 2009 at 8:28 PM, Christian<[hidden email]> wrote:

> On Mon, Aug 3, 2009 at 15:04, Joe Armstrong<[hidden email]> wrote:
>> There's two kinds of stuff:
>>
>>    A) Stuff which doesn't break when you move it
>>    B) Stuff which breaks when you move it
>
> I'm not sure if you were just talking about general design but this example:
>
>> Experiment:
>>
>>    # cd /usr/local/lib
>>    # mv erlang globble
>>    # globble/bin/erl
>>    exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found
>
> This is surely just about the paths inside the script 'erl' itself.
> The ROOTDIR variable in there looks suspicious indeed.
>
> I actually quite like that erl stores the installation directory in
> itself. I prefer it over java's JAVA_HOME environment variable. If I
> want to use a specific java version i have installed I need to set
> JAVA_HOME correctly, AND start the right java binary. In erlang I
> point out what I want and that is what I get.
>
> Since argv[0] / $0 is unreliable for finding the installation dir, I
> think Erlang does the pragmatic best way for being insensitive to what
> its installation dir is.
>
> Also, about HTML, what some (you?) perceive as a disadvantage is
> someone else's advantage. If every HTML document would include the
> pictures, scripts and css, then you would have to load all that even
> if those parts were the same.

The great ones said  "verily verily I say unto you, premature
optimization is the root of all evil"

And this, my friend, is a premature optimization. Not only is it a
premature optimization
it is a widely spread notion that this is a good thing to do - but it
is practice that
causes incredibly large amounts of time to be wasted because HTML can
break when you relocate it.

If you *want* to optimize then it's easy - imagine storing two zip
files zip1 and zip2 on
 machine A. A remote machine B first downloads zip1, then it wants
zip2, a simple diff algorithm/protocol can be used to recreate zip2 on
B by asking A to send the diffs between A and B.

This should be totally invisible to the user.

If file A includes B then it is a law of nature that if you move A
from machine to machine you will
one day loose B. If the versions of A and B matter then one day you
will include the wrong
version of B in A unless you have a version control system that
guarantees correctness.

If you put all your HTML etc. in a revision control system (or
database) and have strong
guarantees on consistency then fine - but most systems I see are not
build this way - and
they break when you move them.

The (fundamental) difference between PDF and HTML is that I can send a
PDF file to anybody,
or put it in a storage system and retrieve it years later and still
see the entire document.

Sending an HTML file to a remote location (or storing it) in such a
way that the content can be reproduced years later is highly error
prone since it relies on an out-of-band mechanism to
ensure that *all* the sub-components are also stores in a consistent
way. Worse, this
out-of-band mechanism is not standardized. There are no such problems
with PDF everything
is self contained.

Software should not break when you move a file to a new directory - if
it does this is a
symptom of a deep-seated design problem. Go look at some HTML ages stored in
the Internet Archive (www.archive.org) already many pages lack
associated images.

Imagine you're a historian in 1000 years time - at least with PDF
files you have a chance
to recover the data because you've got all the bits.

If an application consists of a number of parts (and an HTML file with
links to images and javascript can be considered as such) then it
possible to break the application by moving
some of the parts. In a well designed system this should be impossible.

It should be impossible to move something without moving all the
component parts.

Another way to fix this would be to fix "mv" - ie  "mv" *sghould* move
zip files etc withouit complaining - but if asked to move an HTML file
it would also miove any relative components
in a consistent way so as not to break the application.

So something is deeply wrong - either "mv" or html (in this example) -
I guess this is
one reason why "putting everything into a database" is not such a bad
idea - since
your can move the database as a whole, and have strong consistency
checks on the data
when you change it.

/joe

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Joe Armstrong-2
In reply to this post by Dave Pawson-2
On Mon, Aug 3, 2009 at 8:20 PM, Dave Pawson<[hidden email]> wrote:

> 2009/8/3 Joe Armstrong <[hidden email]>:
>
>> I consider them broken in the sense that they will not display the same
>> thing if moved - I'm comparing them with PDF files which do  not break
>> when moved. Now you can embed js, css and even jpgs into the html
>> so that they do work if moved but nobody does this.
>
> Hopefully.
> And for good reason Joe.
> The 'cascade' provides for users to override CSS for such
> as accessibility reasons.
>
> Embedded CSS (and js for that matter) should be history by now.

M'lord I object, the witness is not a historian, the history of HTML
and why is was a bad idea
has not yet been written.

Judge: Do you have any other comments? Try to keep them short, we will recess in
twenty minutes.

I will try, M'lord, if the court will permit ...

Judge: get on with it ...

Ladies and Gentelmen of the Jury,

Image I have a a single web page with some js. I *never* intent to
reuse the js in
a second page. This is a one-off application.

You are saying that I should store this in *two* pages - not one. This
will have the
following consequences:

    - One day I will move one of the files but not the other (I'll
lose the js, for example)
    - the two files will live lives of their own and I'll get into
version nightmares
    - fetching the file has not got transaction semantics. I might get
the HTML and then
      get a link failure before fetching the js. I'd like to "either
fetch both and it works"
       or "fetch nothing" - the thing I use (firefox) doesn't have
transaction semantics.

<< suppose the HTML always assumes the js will be downloaded -
       the HTML prints some static content, then calls the JS - but
the JS is not loaded
       the net consequence of this is that some text is displayed and
this  has disasterous
       consequnces, somebody dies or something. This is because the JS
was not executed.

       Learned council can check if this has actually happened >>

    To avoid these things I have to set up a revision control system
to make sure the parts
cannot be separated - I have to change web browsers for transaction semantics.
pending this we should ask for a court injunction to stop all browsers.

     My solution is to put the js in the file. With one file all the
above problems disappear.

      It's a fundamental law of physics - if you have two things in
two different places
it's impossible to agree if they are in a consistent state - it's
mathematically impossible
(see http://en.wikipedia.org/wiki/Two_Generals'_Problem).

    There are *pragmatic* benefits of including css, js files - but
this is a premature optimization
and the net effect of include files can be achieved by a different
(and sound) mechanism

    I rest my case M' lord.

Cheers

/Joe



> regards
>
>
>
>
>
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> Docbook FAQ.
> http://www.dpawson.co.uk
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Dave Pawson-2
In reply to this post by Joe Armstrong-2
2009/8/4 Joe Armstrong <[hidden email]>:

> Sending an HTML file to a remote location (or storing it) in such a
> way that the content can be reproduced years later is highly error
> prone since it relies on an out-of-band mechanism to
> ensure that *all* the sub-components are also stores in a consistent
> way. Worse, this
> out-of-band mechanism is not standardized.


Agreed. Not standardised, simply a recommendation.
From the authors of HTML, Tim and Friends at W3C.
They don't write standards.

Loosely though, it's been 'standard' since about html 3.1

Just so happens that you need the images, js, CSS as
a number of files to make up a package that is viewable.
   Live with it, or use PDF.


regards


--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Roger Price-6
In reply to this post by Joe Armstrong-2
On Tue, 4 Aug 2009, Joe Armstrong wrote:

> M'lord I object, the witness is not a historian, the history of
> HTML and why is was a bad idea has not yet been written.

When written, it may even say that TBL took ideas from SGML but did
not take the OASIS catalog intended to mitigate the "N files"
problem.

Roger

(Will it tell us about the meeting between TBL and CFG?
Can I preorder?)

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Vlad Dumitrescu-2
In reply to this post by Joe Armstrong-2
Hi Joe,

I see your point and can't really say I disagree, but I'm not sure if
I understand correctly what you're after.

First, the one-off case isn't the most common. Most of the time, one
wants to be able to share common resources.

For one-off documents, one can include all needed resources, one way
or another (most of the time). For example, you could include images
as json data that are rendered with javascript. Clunky, but possible.
Can be automated with a tool, so instead of zipping the separate
files, you pack them with another command.

Second, PDF files can still reference external resources, fonts and
even images (I think). So just by having a PDF file, you're not
certain that it is self-contained and you can view it as the author
intended.

Third, how do you draw the line between resources that are to be
embedded and those that aren't? Examples of the first category may be
images, fonts, properties files. The other category would include the
application to view the file, the C libraries it requires, a
compatible OS and a compatible hardware. The delimitation depends on
the specifics of your case and what works well for one-off projects
might be very wrong for a large distributed one.

Or did I misunderstand you?

best regards,
Vlad

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Re: Stuff that breaks when you move it

Michael Richter
In reply to this post by Joe Armstrong-2
Sounds to me, Joe, that you're looking for something like the Fossil SCM  
(http://www.fossil-scm.org) unless I'm misreading something very badly.

On Aug 4, 2009 3:53pm, Joe Armstrong <[hidden email]> wrote:
> Image I have aa single web page with some js. I *never* intent to reuse  
> the js in
> a second page. This is a one-off application.

> You are saying that I should store this in *two* pages - not one. This  
> will have the
> following consequences:
Reply | Threaded
Open this post in threaded view
|

Re: Re: Stuff that breaks when you move it

Joe Armstrong-2
Wow - your read me correctly - amazing stuff. This is really itching
my programmers nerve.

So in Erlang we have dets files (containers) - a web server is trivial
- diffing is easy -
compression is easy - crypto is easy. Files are named by their SHA1 checksum and
signed with an RSA key - trees are named by SHA1 of term_to_binary(Tree) etc.

Embedding everything into a single file and signing all the trees
seems to be like
some kind of munge of the ideas in GIT and zip. This (fossil) stuff
looks well worth
studying - reading the Fossil documentation rings all the right bells - thanks
for the link.

/Joe



On Tue, Aug 4, 2009 at 12:42 PM, <[hidden email]> wrote:

> Sounds to me, Joe, that you're looking for something like the Fossil SCM
> (http://www.fossil-scm.org) unless I'm misreading something very badly.
>
> On Aug 4, 2009 3:53pm, Joe Armstrong <[hidden email]> wrote:
>> Image I have a a single web page with some js. I *never* intent to reuse
>> the js in
>> a second page. This is a one-off application.
>
>> You are saying that I should store this in *two* pages - not one. This
>> will have the
>> following consequences:

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

harveyd
In reply to this post by Joe Armstrong-2
it is not premature as it is one of the major bottlenecks when trying to
build fast loading websites, large enough that the yahoo performance team
specifically recommend you make css / js external (except for possibly the
home page)

http://developer.yahoo.com/performance/rules.html


2009/8/4 Joe Armstrong <[hidden email]>

> On Mon, Aug 3, 2009 at 8:20 PM, Dave Pawson<[hidden email]> wrote:
> > 2009/8/3 Joe Armstrong <[hidden email]>:
> >
> >> I consider them broken in the sense that they will not display the same
> >> thing if moved - I'm comparing them with PDF files which do  not break
> >> when moved. Now you can embed js, css and even jpgs into the html
> >> so that they do work if moved but nobody does this.
> >
> > Hopefully.
> > And for good reason Joe.
> > The 'cascade' provides for users to override CSS for such
> > as accessibility reasons.
> >
> > Embedded CSS (and js for that matter) should be history by now.
>
> M'lord I object, the witness is not a historian, the history of HTML
> and why is was a bad idea
> has not yet been written.
>
> Judge: Do you have any other comments? Try to keep them short, we will
> recess in
> twenty minutes.
>
> I will try, M'lord, if the court will permit ...
>
> Judge: get on with it ...
>
> Ladies and Gentelmen of the Jury,
>
> Image I have a a single web page with some js. I *never* intent to
> reuse the js in
> a second page. This is a one-off application.
>
> You are saying that I should store this in *two* pages - not one. This
> will have the
> following consequences:
>
>    - One day I will move one of the files but not the other (I'll
> lose the js, for example)
>    - the two files will live lives of their own and I'll get into
> version nightmares
>    - fetching the file has not got transaction semantics. I might get
> the HTML and then
>      get a link failure before fetching the js. I'd like to "either
> fetch both and it works"
>       or "fetch nothing" - the thing I use (firefox) doesn't have
> transaction semantics.
>
> << suppose the HTML always assumes the js will be downloaded -
>       the HTML prints some static content, then calls the JS - but
> the JS is not loaded
>       the net consequence of this is that some text is displayed and
> this  has disasterous
>       consequnces, somebody dies or something. This is because the JS
> was not executed.
>
>       Learned council can check if this has actually happened >>
>
>    To avoid these things I have to set up a revision control system
> to make sure the parts
> cannot be separated - I have to change web browsers for transaction
> semantics.
> pending this we should ask for a court injunction to stop all browsers.
>
>     My solution is to put the js in the file. With one file all the
> above problems disappear.
>
>      It's a fundamental law of physics - if you have two things in
> two different places
> it's impossible to agree if they are in a consistent state - it's
> mathematically impossible
> (see http://en.wikipedia.org/wiki/Two_Generals'_Problem<http://en.wikipedia.org/wiki/Two_Generals%27_Problem>
> ).
>
>    There are *pragmatic* benefits of including css, js files - but
> this is a premature optimization
> and the net effect of include files can be achieved by a different
> (and sound) mechanism
>
>    I rest my case M' lord.
>
> Cheers
>
> /Joe
>
>
>
> > regards
> >
> >
> >
> >
> >
> >
> > --
> > Dave Pawson
> > XSLT XSL-FO FAQ.
> > Docbook FAQ.
> > http://www.dpawson.co.uk
> >
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Mazen Harake-2
In reply to this post by Joe Armstrong-2
On what level is P-1 suppose to work?

Should I be able to move the erlang directory?
Should I be able to move the lib directory?
Should I be able to move the applications in the lib directory?
Should I be able to move the beams in the applications directory?
Should I be able to move the bytes around in the beams?

Basically you will give people that support convention a big head ache.
I agree that some things you should be able to be moved without them
breaking but you must DEFINE the units. When you say "Erlang", what
exactly do you mean? You can't build anything using components without
having either a convention or a mediator on how they should find each
other.

If you choose convention then you by definition _can't_ move it around
unless you define each unit that you can move, but then you need some
convention to move the movable unit around and so on...... unless you
are going to bake your whole system into one extreamly large binary blob
you won't get away from the fact that things will break as soon as you
have two entities... but even if you _do_ have a huge blob you still
want to split it up and find information in it and voila (I believe that
is how it is spelt) you are back to square one.

The only option (I believe) is to have a mediator that tells you where
things are... and that mediator is the only thing that _all_ the
units/enteties use to find other entities. And if something is moved, it
can only be moved using that mediator and all calls have to go through
this mediator (serialized) otherwise you have race conditions all over.

This pretty much kills P-1 and P-2....

P-3 and P-4 however make perfect sense and should be part of any system.

/Mazen

Joe Armstrong wrote:

> There's two kinds of stuff:
>
>     A) Stuff which doesn't break when you move it
>     B) Stuff which breaks when you move it
>
> Type A includes:
>     zip files,  PDF files, jpg files, mp3 files, ...
>
>
> Type B includes:
>      Erlang, HTML files, DRM protected files, erlang beam files, ...
>
>
> A good general principle is:
>
>     P-1 - "Stuff should not break if you move it to a new directory"
>
> A is good B is bad.
>
> Experiment:
>
>     # cd /usr/local/lib
>     # mv erlang globble
>     # globble/bin/erl
>     exec: 28: /usr/local/lib/erlang/erts-5.7.1/bin/erlexec: not found
>
> Thus Erlang is in B.
>
> But it doesn't have to be so - this is a bug not a feature
>
> Note: 1) This problem (stuff breaking when you move it) is
> a particular pain when you have to make something work
> that depends upon several different components and each one
> individually breaks when you move it.
>
> 2) Sometimes stuff cannot be moved to where the author wanted
> you to move it to. So if you have not got admin rights
> you *cannot* move your program to /bin (or whatever)
>
> So lets add:
>
>      P-2: It should be possible to move stuff to *any*
>           directory in the file system to which you have write access
>           without breaking it.
>
> And while we're on the subject:
>
>      P-3: We should be able to *remove* stuff without breaking
>      other stuff that is not dependent upon the stuff we have removed.
>
>  And
>
>      P-4: If we add stuff to the system and then remove it we should put
>      the system back to the state it was in before we added the
>      stuff that we removed. (Possibly we might change the state of the
>      system log to say that we have added and removed something,
>      but nothing else should happen)
>
> Very little software obeys principles P-1 to P-4.
>
> This is bad.
>
> Fix it.
>
> Cheers
>
> /Joe
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>  


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: Stuff that breaks when you move it

Fred Hebert (MononcQc)
In reply to this post by Joe Armstrong-2
On Tue, Aug 4, 2009 at 3:53 AM, Joe Armstrong<[hidden email]> wrote:
> On Mon, Aug 3, 2009 at 8:20 PM, Dave Pawson<[hidden email]> wrote:
>> 2009/8/3 Joe Armstrong <[hidden email]>:
>>
>
> M'lord I object, the witness is not a historian, the history of HTML
> and why is was a bad idea
> has not yet been written.
>
> Judge: Do you have any other comments? Try to keep them short, we will
recess in

> twenty minutes.
>
> I will try, M'lord, if the court will permit ...
>
> Judge: get on with it ...
>
> Ladies and Gentelmen of the Jury,
>
> Image I have a a single web page with some js. I *never* intent to
> reuse the js in
> a second page. This is a one-off application.

- That's a valid time for some JS. However, lots of webpage end up re-using
javascript and css on more than a page: menu highlights, header and footer
styles, etc.

> You are saying that I should store this in *two* pages - not one. This
> will have the
> following consequences:
>
>    - One day I will move one of the files but not the other (I'll
> lose the js, for example)
>    - the two files will live lives of their own and I'll get into
> version nightmares

Version nightmare will also be a possibility in case of having to maintain
the same file over many pages, It's partially why files are split the way
they are right now. Of course if it's a one-time use, nothing would keep you
from having it embed in the page and fixing that problem, but in every other
circumstance ever reusing the code, splitting it over many files is the way
to go.


>    - fetching the file has not got transaction semantics. I might get
> the HTML and then
>      get a link failure before fetching the js. I'd like to "either
> fetch both and it works"
>       or "fetch nothing" - the thing I use (firefox) doesn't have
> transaction semantics.
>
> << suppose the HTML always assumes the js will be downloaded -
>       the HTML prints some static content, then calls the JS - but
> the JS is not loaded
>       the net consequence of this is that some text is displayed and
> this  has disasterous
>       consequnces, somebody dies or something. This is because the JS
> was not executed.
>
>       Learned council can check if this has actually happened >>

Javascript is often (as it should be) not necessary to the functionning of a
page. Same for CSS. It should be able to downgrade gracefully. If it
doesn't, it usually is done at the cost of functionality (see webapps like
last.fm or facebook chat). In these cases, no archiving is possible anyway,
given a lot of interaction is needed with the server. Questions of same
origin policies and 'is the server still there?' will ruin that.

I can agree that this is problematic though, as it is for the degradation of
images


>    To avoid these things I have to set up a revision control system
> to make sure the parts
> cannot be separated - I have to change web browsers for transaction
semantics.
> pending this we should ask for a court injunction to stop all browsers.
>


Other advantages of separate files have to do with distribution: in dynamic
applications (serving thens of thousands of people), you want the actual
servers to do as much computing as possible, not using server resources
reading files from disk to send them to people.

As easily over 90% of a page size (and load time) is in its static files,
what you end up doing is using Content Delivery Networks (CDNs). CDNs an
infrastructure of servers located all around the world with the only
objective of delivering static content really fast. What they do by being on
a different domain is allowing you to download files simultaneously (more
than if they were embedded on the page), and faster due to proximity of
servers and fine-tuning of everything needed.

The following time the file is encountered, it is not even downloaded as
it's kept in the browser. By using a diff, assuming a diff like the ones we
have right now, is dowloading the changing line not once, but twice. One for
the old line, one for the new line. You also deny the use of CDNs, making
costs of bandwidth for many corporations much higher and load time for users
much longer.

You also want to send data as fast of possible, possibly sending every bit
of text you've got before the page is even done loading. This is done by
outputing parts of some pages as fast as possible when they're ready. By
using a diff, you still need to generate the whole page, and then have the
server compare data to make a diff file to send.

Getting the diff done can be longer than just sending a new page over in
these circumstances.

It's also unclear what a diff would do to things like a chunked file
sending, how it'd react to javascript queries.


>     My solution is to put the js in the file. With one file all the
> above problems disappear.
>
>      It's a fundamental law of physics - if you have two things in
> two different places
> it's impossible to agree if they are in a consistent state - it's
> mathematically impossible
> (see http://en.wikipedia.org/wiki/Two_Generals'_Problem).
>
>    There are *pragmatic* benefits of including css, js files - but
> this is a premature optimization
> and the net effect of include files can be achieved by a different
> (and sound) mechanism

Given all the above, I would say it is NOT premature optimization when you
know from the beginning you will have tens of thousands of simultaneous
viewers at all time (over millions a month).

It is although useful when you want to archive documents because changes and
updates no longer interest you. This is -- I believe -- the biggest
difference.
The step needed to change a page from dynamic to static for archival and
portability purposes requires you to separate it from its origins; you go
through it with wget, which will change URLs, download dependent files and
store them on your computer. This would be the equivalent of a compiler
linking the files into a single executable and the .dlls around it in some
cases.

Or, if we take it back to Erlang, I see multiple files as the difference
between defining all your functions in a single Erlang application file
(reimplementing the standard library functions inseatd of -import()ing
them), rather than counting on the system to do what is necessary to load
files.

Of course I may not exactly get exactly what you mean, but there are
extremely good reasons to keep content separate in the case of web files and
applications. You'd have to consider them for Erlang too.
12