HTTP interface

[friggeri]

Just wondering if some kind of network capability/interface was planned to be included in the core, or does something like this belongs to a library :

abstract Verb
abstract Get    <: Verb
abstract Post   <: Verb
abstract Put    <: Verb
abstract Delete <: Verb

type Url
    url::String
end

macro url_str(p)
    Url(p)
end

# Catch all unknown HTTP verbs
function open{T<:Verb}(url::Url, ::Type{T}) 
    error("Verb $(T) not implemented")
end

# Actual implementation for GET
function open(url::Url, ::Type{Get}) 
    # here would go the implementation
    return "Yada yada content"
end

# Assume GET if no method is specified
open(url::Url) = open(url, Get)

# Examples
print(open(url"http://www.julialang.org"))
print("\n\n")
print(open(url"http://www.julialang.org", Post))

Output :

Yada yada content

Verb Post not implemented
in error, /Users/adrien/Sources/julia/j/error.j:5
in open, http.j:17
in include, src/boot.j:192
in process_options, /Users/adrien/Sources/julia/j/client.j:163
in _start, /Users/adrien/Sources/julia/j/client.j:201
at http.j:32

[StefanKarpinski]

Doesn't exist. Would be a great addition.

[ViralBShah]

Timo Sulg posted on the list about integrating libcurl.

http://groups.google.com/group/julia-dev/browse_thread/thread/a381c80577ccbfc5/e7b49fee4925c767?hl=en&lnk=gst&q=curl#e7b49fee4925c767

[friggeri]

Well this was pretty much exactly what I was planning to write. I'll have to find another pet project to play with Julia !

[StefanKarpinski]

You guys could collaborate :-)

[yocontra]

Any chance we can use libuv for this feature?

[StefanKarpinski]

I haven't looked into it enough, but I suspect we should embrace libuv, and if we do, we should use it wherever possible.

[JeffBezanson]

I would say this doesn't need to be addressed as part of julia itself.

[ViralBShah]

Not right away, but eventually, if we do want to include a package system, for example, we may need to have at least http and zlib as part of the core.

[JeffBezanson]

I know these package systems are useful, no question. But I really feel the idea that every language needs its own package manager should make us think twice about how our systems are designed. What is going on here?

[ViralBShah]

That's what every language has asked, and then built their own! I think our package manager should just be:

load("http://foo.com/bar.jlpkg")

Where bar.jlpkg is a directory with all the stuff that one needs. Could be made to work for binaries too, but certainly good enough for pure julia code. Of course, the local system could cache downloaded packages, etc.

-viral

On 10-Mar-2012, at 9:48 AM, JeffBezanson wrote:

I know these package systems are useful, no question. But I really feel the idea that every language needs its own package manager should make us think twice about how our systems are designed. What is going on here?

---

Reply to this email directly or view it on GitHub:
#433 (comment)

[StefanKarpinski]

That approach is fine for doing development work but it would be horrible for deployed systems: someone upgrades the version of the code at the URL and suddenly your deployed systems all break. Awesome. This isn't hypothetical, I've experienced this using a similar system.

An interesting (and simple) approach to package management that's occurred to me is to just base the package management heavily on git. Each package is a repo — with a URL that git can fetch. If we you use the HTTPS protocol, then you even get SSL encryption and cert verification and such. Also, you have immediate access to all versions of the package: just do a git checkout of that version and then use it. It also means we don't have to implement any protocols for fetching stuff — just let git do all the work. Since GitHub exists, people can easily use it for Julia package hosting and all the tools for working on shared code are already in place.

[ViralBShah]

Yes, git is a great idea. Would we be tied to using github, or could anyone serve a package from any git server exhibiting https?

-viral

On 10-Mar-2012, at 10:16 PM, Stefan Karpinski wrote:

That approach is fine for doing development work but it would be horrible for deployed systems: someone upgrades the version of the code at the URL and suddenly your deployed systems all break. Awesome. This isn't hypothetical, I've experienced this using a similar system.

An interesting (and simple) approach to package management that's occurred to me is to just base the package management heavily on git. Each package is a repo — with a URL that git can fetch. If we you use the HTTPS protocol, then you even get SSL encryption and cert verification and such. Also, you have immediate access to all versions of the package: just do a git checkout of that version and then use it. It also means we don't have to implement any protocols for fetching stuff — just let git do all the work. Since GitHub exists, people can easily use it for Julia package hosting and all the tools for working on shared code are already in place.

---

Reply to this email directly or view it on GitHub:
#433 (comment)

[StefanKarpinski]

No, any git URL would work. GitHub would just be handy.