| Author |
Message |
|
| Guest |
 Posted: Tue Sep 13, 2011 7:53 pm |
 |
|
|
Guest
|
On Tue, Sep 13, 2011 at 9:44 PM, David Goehrig <dave@nexttolast.com> wrote:
> This is basically how most real world JavaScript applications already work, so it simply falls to building a nice distributed registry that can be universally queried.
I was thinking of statically using the information to fetch and
update the code. But you could do it dynamically by hacking the
code loader and caching the results. I guess you could just say
-location(mymod,"http://ww.a.b/foo/mymod.erl")
and use a regular web server to serve up the code and cache the result.
To implement this you'd just need a parse transform and a small hack
to error_handler.erl and code.erl
I would do this myself but I'm off on holiday tomorrow with no computer
/Joe
>
> Erlang txt fields in DNS anyone?
>
> Also since rebar already allows you to specify your dependencies as git tags, we already have a system that will automatically pull the specific source (or latest if unspecified) and build your application.
>
> Dave
>
> -=-=- dave@nexttolast.com -=-=-
>
> On Sep 13, 2011, at 3:19 AM, Joe Armstrong <erlang@gmail.com> wrote:
>
>> I had an idea on my way to work ...
>>
>> When you write code, you have *implicit* knowledge of where the
>> external code comes from.
>>
>> When I write the following:
>>
>> |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Sep 13, 2011 7:55 pm |
|
|
|
Guest
|
On 2011-09-13, at 21:44 , David Goehrig wrote:
> This is basically how most real world JavaScript applications already work
in-browser, I don't know any server-side javascript implementation which fetches modules over HTTP when importing by default. In fact, the CommonJS "require" spec does not allow allow the colon character at all.
> so it simply falls to building a nice distributed registry that can be universally queried.
Regardless of remote-loading (which would ideally require signed everything), finally having an easy to use and community-accepted CPAN.pm or gem-type tool for Erlang would be quite nice. Even linked to a pypi-type centralized repository.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Sep 13, 2011 8:29 pm |
|
|
|
Guest
|
Am 13.09.11 21:53, schrieb Joe Armstrong:
> On Tue, Sep 13, 2011 at 9:44 PM, David Goehrig <dave@nexttolast.com> wrote:
>> This is basically how most real world JavaScript applications already work, so it simply falls to building a nice distributed registry that can be universally queried.
> I was thinking of statically using the information to fetch and
> update the code. But you could do it dynamically by hacking the
> code loader and caching the results. I guess you could just say
>
> -location(mymod,"http://ww.a.b/foo/mymod.erl")
Sorry for my ignorance, I have not written much erlang (unfortunately).
But just to get this concept -location is a clause directing the laoder,
right?
So you have three entities:
a) the exporter site (exporting mymod)
b) the importer site (depending on mymod)
c) the loader (knowing where to find mymod)
Where a) and b) should be transparent of c). So you can plug in
different loders and load code from different sources.
Where is code depended by mymod loaded then?
In Javascript (CommonJS module system) the trick is to interpret a code
site as a closure and pass in a function called require as a parameter
(for hygenic reasons) when evaluating the code loaded from a location,
that has a certain lookup rule for again loading code (relative to that
site).
What about security issues - can you trust www.a.b even if it depends on
some internal modules (that are not sandboxed)?
Where would such a -location annotation typically be placed? Can you
give me an example?
Since you have more deployments than libraries and applications there
needs to be some wiring.
Cheers,
Jakob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Sep 13, 2011 11:29 pm |
|
|
|
Guest
|
On Sep 13, 2011, at 4:28 PM, Jakob Praher <jakob@praher.info (jakob@praher.info)> wrote:
Quote: What about security issues - can you trust www.a.b even if it depends on
some internal modules (that are not sandboxed)?
Do you trust the code you download via cpan, gems, easy_install, npm, yum, apt, or your favorite module system here?
Even if you have PGP signatures and programmatically check them, you still implicitly trust the developer whose code you are using. The best you can do is lock down to an assumed good state and save the hash. |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 14, 2011 12:13 am |
|
|
|
Guest
|
On Wed, Sep 14, 2011 at 01:29, David Goehrig <dave@nexttolast.com> wrote:
> My suspicion is in the long term systems will continue to be so complex no
> one will be able to verify trust, and we'll adapt by living with a certain
> level of insecurity and abuse.
Well, there is one way out, but it is not particularly implemented,
nor easy to pull off. George Necula has written a paper on
proof-carrying-code. Here is the trick.
We start by setting up a security policy. The SP has to be formally
specified since we want a machine to check it. Necula does this for
out-of-bounds memory checks, but you can in principle do it for any
security predicate you want, as long as you are able to make a
formulation of it formally. When we all agree on an SP, the next step
can begin.
The author of the code is obliged to pass two things. The code C, and
a proof P which states that the code obeys the SP. From C a set of
verification conditions are extracted which must be true for SP to
hold. The proof P is a list of how to show these conditions to be
true. How the author comes up with P is interesting. Basically you can
have the compiler infer everything about P you need. In a case the
compiler can't prove something, for a memory access it won't be able
to prove it is not out-of-bounds, the compiler inserts enough checking
so it is able to carry out the proof. This is mostly mechanical. The
proof is output as an Oracle stream which allows us to compress the
size of the proof down. The idea is that the oracle stream provides a
set of hints about what to do if an automated proof checker gets
stuck.
The user of the code gets C and P. He then proceed by using a
verification condition generator on C which tells him what conditions
need to be true - the same generator which the author uses. And he
uses P on the conditions to check that the proof actually is the right
one. If the proof goes through, he may use the code.
The beauty of the approach is that the user of the code does not have
to trust the author. They only have to agree on SP. If the Code is
altered, the Proof may or may not work. If it works, it is still safe.
If not, we can reject the program. If the proof is altered, it may or
may not work. if it works, it is still safe. If not, we can reject the
proof (and thus the program).
Now, it is a 10 year old idea. So why hasn't it seen more use? For
one, it requires some compiler tech support. Then there is the whole
part about SP, which can be pretty nasty to build up. My bet is that
it has to incubate for more years, until our knowledge about
mechanical theorem proving is better.
But a dreamy vision it is! It would allow us to distribute code over
the internet, and execute code from untrusted sources, just by
checking that the proof they provide is correct.
--
J.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| jeffm |
| Posted: Wed Sep 14, 2011 1:18 am |
|
|
|
User
Joined: 29 Sep 2008
Posts: 43
|
You appear to be the first person in this thread that has addressed the
question that I've been thinking. "How to find the repository?" Most, so
far, have used fixed URLs, but as we all know these tend to be out of
date on a regular basis. The larger the project, the more dependency,
the more you desperately need this thing to work, the more pushed for
time you are, the more likely you are to find that the site which has
the module you need is down or no longer exists. Here's roughly what
I've been think as I read this thread,
Have a file which lists mirror sites from which you can pull a list of
repositories. Much like the /etc/resolve.conf file for dns.
Have a global conf file to tune repo/lookup site selection and other
parameters similar to debian package management.
Have a project conf file to fine tune the global settings.
Have a per project file which lists app/module/fun dependances. This
could be auto-generated using tools.
As part of this a tool to make it easy to system packages (eg rpm, deb,
open package, etc).
So far I don't see a need for a -location compiler directive at the
source file level. May be I'm missing something.
However, the app/module/fun dependance list would need a better
signature than app:module:fun/count or version. It's would need some
form of crypto hash. How would you calculate such a hash?
Having a resolution down to the function level would allow you to know
if you can safely upgrade to a future (or past) module version or not
automatically even before compiling. It seems that there are projects
out there that do A+C or A+B, but none that do the full raft of things.
Finally, the key I think is to eliminate single points of failure such
as being reliant on one key website. A P2P module distribution system
would be great.
Jeff.
On 14/09/11 5:44 AM, David Goehrig wrote:
> This is basically how most real world JavaScript applications already work, so it simply falls to building a nice distributed registry that can be universally queried.
>
> Erlang txt fields in DNS anyone?
>
> Also since rebar already allows you to specify your dependencies as git tags, we already have a system that will automatically pull the specific source (or latest if unspecified) and build your application.
>
> Dave
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
 
|
| axel |
| Posted: Wed Sep 14, 2011 6:46 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
Greetings,
This email mentions import renaming. Does that include solving the
problem that two modules I want to load have the same name?
bengt
On Tue, 2011-09-13 at 19:21 +0200, Jesper Louis Andersen wrote:
> On Tue, Sep 13, 2011 at 09:19, Joe Armstrong <erlang@gmail.com> wrote:
> > -location(lists,
> > "https://github.com/erlang/otp/blob/dev/lib/stdlib/src/lists.erl").
>
> > Comments?
>
> I like the idea quite a lot. In a modern world, the whole notion of "a
> module lives on a single file system" is wrong. It is rather the case
> that a module lives its life behind an URI, is subject to change and
> that locally we are more concerned about caching and having the
> correct version. While you are at it, your -location() notion also
> allows for import renaming, which is something that is needed dearly
> in Erlang. Who says a module is in a file? It could be in an HTTP
> stream, or sent over a websocket or XMPP even. There is no reason to
> tie it to a specific carrier.
>
> As for security, security is to be had by forming releases. When you
> create a release, you can use signatures to verify the authenticity of
> modules from module authors. The signature is even present easily in
> git with a merkle-tree-like construction. The alternative, which is
> probably some 20-30 years out in the future is Proof-carrying-code
> where the code itself provides a proof of what it does - so lets stick
> with signatures for now.
>
> Releases also provide a stable notion of the system. It is not subject
> to change once formed.
>
> Then there is the part of self-documenting the dependencies, which I
> also really like. In the Standard ML community, there is a nice MLB
> concept where you can form bundles of software in the large. You can
> say "This application consists of these files, and it exports these
> modules and functors under these (renamed) names". Upon import, you
> can also rename the API names to avoid clashes locally. The standard
> library is just a MLB application reference. The older standard
> library can be had by another reference.
>
> Essentially we have a notion of lexically scoped module availability
> and exportation in the MLB files. But they never considered a world
> where everything is just an URI. Which is why I like the location
> idea. It incorporates that notion, and it is a tighter coupling than
> an external MLB file, which I am not sure is the way to go. In any
> case, if one were to revamp the module system of Erlang, -location()
> should be a consideration.
>
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 14, 2011 3:24 pm |
|
|
|
Guest
|
>
> When I write the following:
>
> |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 14, 2011 4:26 pm |
|
|
|
Guest
|
On Wed, Sep 14, 2011 at 08:46, Bengt Kleberg <bengt.kleberg@ericsson.com> wrote:
> Greetings,
>
> This email mentions import renaming. Does that include solving the
> problem that two modules I want to load have the same name?
Well it depends,
You can rename a module when you import it, or
you can rename a module when you export it.
The latter has no meaning in Erlang. All modules are by default
exported under the name they were written with and there is full
visibility. So in Erlang, only import renaming makes (easy) sense. The
idea is then, that you can write an import declaration with renaming
to make a more digestible name locally in an application. But this
doesn't allow for two modules with the same name in the Erlang
Runtime.
It is silly I have to write etorrent_event:notify/2 when in my
application, event:notify/2 would be as good. On the other hand, it
doesn't save me much in the typing department, and it is another level
of proxying my brain has to process.
Another way is to allow modules of the same name, but add some
qualifier when referring to them. So you can say "The module in the
stdlib application" when you import them.
I initally wanted a more expressive module system because I saw it as
necessary for being able to evolve the standard library, while keeping
the old systems on track. The idea was to bulid an alternative stdlib
next to the current one and then prefer it for applications. I've
however come to the conclusion it would be better to add a tool like
Golangs "gofix". Gofix is an indentation-aware syntax fixer and
library upgrader. The idea is that when the basis library is changed,
gofix can be invoked to automatically bring programs up to date as
well. In many cases the application is completely mechanic and can be
used to ease the burden on programmers when using old versions of the
code.
In Erlang the basis is already there. One just has to consider
Wrangler. With an upgrade tool, we could begin evolving the stdlib to
make it more streamlined and consistent. Since Erlang has no types, we
can't easily fix the order of function arguments, but many other cases
can be fixed - and that while providing backwards compatibility
through mechanical upgrade of old source code. It also avoids the
issue with maintaining more than one standard library.
--
J.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Sep 14, 2011 5:36 pm |
|
|
|
Guest
|
On Sep 13, 2011, at 8:12 PM, Jesper Louis Andersen <jesper.louis.andersen@gmail.com (jesper.louis.andersen@gmail.com)> wrote:
Quote: George Necula has written a paper on
proof-carrying-code. Here is the trick.
I think PCC works only in theory, but would not work in reality. |
|
|
| Back to top |
|
| axel |
| Posted: Thu Sep 15, 2011 7:39 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
In my mind the problem that module renaming should solve is "modules
with the same name in the Erlang Runtime".
The gofix tool, does it handle leagacy/binary code?
bengt
On Wed, 2011-09-14 at 18:26 +0200, Jesper Louis Andersen wrote:
> On Wed, Sep 14, 2011 at 08:46, Bengt Kleberg <bengt.kleberg@ericsson.com> wrote:
> > Greetings,
> >
> > This email mentions import renaming. Does that include solving the
> > problem that two modules I want to load have the same name?
>
> Well it depends,
>
> You can rename a module when you import it, or
> you can rename a module when you export it.
>
> The latter has no meaning in Erlang. All modules are by default
> exported under the name they were written with and there is full
> visibility. So in Erlang, only import renaming makes (easy) sense. The
> idea is then, that you can write an import declaration with renaming
> to make a more digestible name locally in an application. But this
> doesn't allow for two modules with the same name in the Erlang
> Runtime.
>
> It is silly I have to write etorrent_event:notify/2 when in my
> application, event:notify/2 would be as good. On the other hand, it
> doesn't save me much in the typing department, and it is another level
> of proxying my brain has to process.
>
> Another way is to allow modules of the same name, but add some
> qualifier when referring to them. So you can say "The module in the
> stdlib application" when you import them.
>
> I initally wanted a more expressive module system because I saw it as
> necessary for being able to evolve the standard library, while keeping
> the old systems on track. The idea was to bulid an alternative stdlib
> next to the current one and then prefer it for applications. I've
> however come to the conclusion it would be better to add a tool like
> Golangs "gofix". Gofix is an indentation-aware syntax fixer and
> library upgrader. The idea is that when the basis library is changed,
> gofix can be invoked to automatically bring programs up to date as
> well. In many cases the application is completely mechanic and can be
> used to ease the burden on programmers when using old versions of the
> code.
>
> In Erlang the basis is already there. One just has to consider
> Wrangler. With an upgrade tool, we could begin evolving the stdlib to
> make it more streamlined and consistent. Since Erlang has no types, we
> can't easily fix the order of function arguments, but many other cases
> can be fixed - and that while providing backwards compatibility
> through mechanical upgrade of old source code. It also avoids the
> issue with maintaining more than one standard library.
>
>
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 15, 2011 3:11 pm |
|
|
|
Guest
|
On Thu, Sep 15, 2011 at 09:39, Bengt Kleberg <bengt.kleberg@ericsson.com> wrote:
> In my mind the problem that module renaming should solve is "modules
> with the same name in the Erlang Runtime".
I agree it would be a very good thing to solve. It would be nice to
have a solution where you could have multiple modules of the same
names in the runtime. But perhaps it is not a question of renaming
modules, but rather a question of module visibility. Making a module
visible under another name is a way to avoid name clashes.
> The gofix tool, does it handle leagacy/binary code?
No it doesn't. I think the assumption is that the source code is
available. Handling legacy/binary code is a more involved problem.
--
J.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Sep 15, 2011 3:51 pm |
|
|
|
Guest
|
On Thursday, September 15, 2011, Bengt Kleberg wrote:
> In my mind the problem that module renaming should solve is "modules
> with the same name in the Erlang Runtime".
Kind of like an -import_lib directive, saying, for instance, to pull
references to the lists module from a different library than stdlib?
Cheers,
DBM
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| axel |
| Posted: Fri Sep 16, 2011 5:45 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
I can think of ways to make my code flexible enough to handle choosing
between two different modules. What I can not do is to have two modules
called 'lists' loaded/used at the same time.
bengt
On Thu, 2011-09-15 at 17:51 +0200, David Mercer wrote:
> On Thursday, September 15, 2011, Bengt Kleberg wrote:
>
> > In my mind the problem that module renaming should solve is "modules
> > with the same name in the Erlang Runtime".
>
> Kind of like an -import_lib directive, saying, for instance, to pull
> references to the lists module from a different library than stdlib?
>
> Cheers,
>
> DBM
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
| axel |
| Posted: Fri Sep 16, 2011 9:24 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
Since I am working at a place that has all the source, but still does
not accept changing legacy, I think goflex is a no-go. (Sorry about that
feeble attempt of humor).
bengt
On Thu, 2011-09-15 at 17:11 +0200, Jesper Louis Andersen wrote:
> On Thu, Sep 15, 2011 at 09:39, Bengt Kleberg <bengt.kleberg@ericsson.com> wrote:
> > In my mind the problem that module renaming should solve is "modules
> > with the same name in the Erlang Runtime".
>
> I agree it would be a very good thing to solve. It would be nice to
> have a solution where you could have multiple modules of the same
> names in the runtime. But perhaps it is not a question of renaming
> modules, but rather a question of module visibility. Making a module
> visible under another name is a way to avoid name clashes.
>
> > The gofix tool, does it handle leagacy/binary code?
>
> No it doesn't. I think the assumption is that the source code is
> available. Handling legacy/binary code is a more involved problem.
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Post received from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
