Elsewhere

Shomeya: Adding the 'button' class to Drupal submit buttons

Planet Drupal - Fri, 13/03/2015 - 18:25

In just 2 hours my fully finished Foundation 5 (any framework) to Drupal 7 guide will go live. Just for our readers there's 20% off right up until 12pm PDT when the final version goes live!

In honor of integrating frameworks with Drupal, here's some fun code snippets to get you adding classes without using Sass.

Once you have an awesome new framework how do you make the buttons match the awesomeness?

Read more
Categories: Elsewhere

Dirk Eddelbuettel: Why Drat? A Guest Post by Steven Pav

Planet Debian - Fri, 13/03/2015 - 18:04

Editorial Note: The following post was kindly contributed by Steven Pav.

Why Drat?

After playing around with drat for a few days now, my impressions of it are best captured by Dirk's quote:

It just works.

Demo

To get some idea of what I mean by this, suppose you are a happy consumer of R packages, but want access to, say, the latest, greatest releases of my distribution package, sadist. You can simply add the following to your .Rprofile file:

drat::add("shabbychef")

After this, you instantly have access to new releases in the github/shabbychef drat store via the package tools you already know and tolerate. You can use

install.package('sadists')

to install the sadists package from the drat store, for example. Similarly, if you issue

update.packages(ask=FALSE)

all the drat stores you have added will be checked for package updates, along with their dependencies which may well come from other repositories including CRAN.

Use cases

The most obvious use cases are:

  1. Micro releases. For package authors, this provides a means to get feedback from the early adopters, but also allows one to push small changes and bug fixes without burning through your CRAN karma (if you have any left). My personal drat store tends to be a few minor releases ahead of my CRAN releases.

  2. Local repositories. In my professional life, I write and maintain proprietary packages. Pushing package updates used to involve saving the package .tar.gz to a NAS, then calling something like R CMD INSTALL package_name_0.3.1.9001.tar.gz. This is not something I wanted to ask of my colleagues. With drat, they can instead add the following stanza to .Rprofile: drat:::addRepo('localRepo','/mnt/NAS/r/local/drat'), and then rely on update.packages to do the rest.

I suspect that in the future, drat might be (ab)used in the following ways:

  1. Rolling your own vanilla CRAN mirror, though I suspect there are better existing ways to accomplish this.

  2. Patching CRAN. Suppose you found a bug in a package on CRAN (inconceivable!). As it stands now, you email the maintainer, and wait for a fix. Maybe the patch is trivial, but suppose it is never delivered. Now, you can simply make the patch yourself, pick a higher revision number, and stash it in your drat store. The only downside is that eventually the package maintainer might bump their revision number without pushing a fix, and you are stuck in an arms race of version numbers.

  3. Forgoing CRAN altogether. While some package maintainers might find this attractive, I think I would prefer a single huge repository, warts and all, to a landscape of a million microrepos. Perhaps some enterprising group will set up a CRAN-like drat store on github, and accept packages by pull request (whether github CDN can or will support the traffic that CRAN does is another matter), but this seems a bit too futuristic for me now.

My wish list

In exchange for writing this blog post, I get to lobby Dirk for some features in drat:

  1. I shudder at the thought of hundreds of tiny drat stores. Perhaps there should be a way to aggregate addRepo commands in some way. This would allow curators to publish their suggested lists of repos.

  2. Drat stores are served in the gh-pages branch of a github repo. I wish there were some way to keep the index.html file in that directory reflect the packages present in the sources. Maybe this could be achieved with some canonical RMarkdown code that most people use.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: Elsewhere

Promet Source: Drupal in Gov: Open source platforms & civic website development

Planet Drupal - Fri, 13/03/2015 - 17:52
Why Drupal is the perfect solution for civic website projects  
Categories: Elsewhere

Wouter Verhelst: New toy: Fujitsu Lifebook e734

Planet Debian - Fri, 13/03/2015 - 17:30

My Lenovo x220, which I've owned for almost four years now (I remember fetching it from the supplier shortly before driving off to Banja Luka), was getting somewhat worn out. The keyboard and the screen had both been replaced at some point already, and the wwan interface had given up as well. The case was all cracked, and the NIC connector wasn't doing very well anymore either; there have been a few cases of me trying to configure the wireless network at a customer, but this being harder than it needs to be because the NIC will only work if I put in the network cable just so, and someone dropped a piece of paper onto the cable.

In other words, it was time for a new one. At first I wanted to buy a Lenovo x250, but then I noticed that the Fujitsu came with an i7 4712MQ, which I liked (as today it is still quite exceptional for an ultrabook to have a quadcore processor). Fujitsu also claims up to 9 hours of battery life, but it's not clear to me whether this is supposed to be the case with the default battery only. They also have a battery for the modular bay, which I bought as well (to replace the optical drive whic I sometimes use, but only rarely), and on top of that it came with a free port replicator.

Not all is well, however. In the x220, getting the WWAN interface to work involved some creative use of chat against /dev/ttyACM0 wherein I issue a few AT commands to put the WWAN interface into a particular mode, and from then on the WWAN interface is just a regular Ethernet interface on which I can do DHCP. The new laptop has a "Sierra Wireless, Inc." WWAN interface (USB id 1199:9041) which annoyingly doesn't seem to expose the ttyACM (or similar) devices, and I'm not sure what to use instead. Just trying to do DHCP doesn't work -- yes, I tried.

Unfortunately, the keyboard isn't very good; it's of the bubble gum type, and I keep getting annoyed at it not picking up my keystrokes all the time. When I'm at home or at my main customer, I have a Das Keyboard Ultimate S (3rd (customer) and 4th (home) generation), so it's only a problem when I'm not at home, but it's still extremely annoying. There is a "backlight" function in that keyboard, but that's not something I think I'll ever use (hint: "das keyboard ultimate s").

The display can't do more than 1366x768, which is completely and utterly wrong for a computer -- but it's the same thing as my x220, so it's not really a regression.

The "brightness" ACPI keys don't seem to work. I may have to fiddle with some ACPI settings at some point, I suppose, but it's not a major problem.

When I plugged it in, I noticed that fdpowermon ignored the second battery. I had originally written fdpowermon with support for such a second battery, but as my x220 had only one, I never tested it. Apparently there was a bug, but that's been fixed now -- at least in unstable.

On the good side of the equation, it has three USB3 ports in the laptop, and four in the port replicator, with no USB2; this is a major leap forwards from the one USB3 and six USB2 in the x220. A positive surprise was the CCID smartcard reader that I somehow missed while reading the specs, but which -- given my current major customer, is very welcome, indeed.

Categories: Elsewhere

Mediacurrent: Mediacurrent Acquired by Code and Theory: Our Journey

Planet Drupal - Fri, 13/03/2015 - 15:00

We are proud to announce that Mediacurrent has been acquired by Code and Theory, an independent creative agency that creates products, content and campaigns across physical and digital worlds.

The combined company will bring together more than 350 extremely talented people, and assemble one of the most formidable, independently-owned creative agencies in the world.

Categories: Elsewhere

Code Karate: Adding Git to an existing Drupal project

Planet Drupal - Fri, 13/03/2015 - 14:11

I recently received an email from someone who finished reading the

Categories: Elsewhere

Lior Kaplan: PHP7 replaces non-free JSON extension

Planet Debian - Fri, 13/03/2015 - 10:42

For many the PHP JSON extension license might look like a storm in a teacup, but for many Linux distributions the bits of the free software licenses are very important. That was the case when Debian decided (#692613) to remove the non-free JSON extension as part of the transition to PHP 5.5 in May 2013 (after the Debian 7 release).

This change was done with the help of Remi Collet (from Fedora / Red Hat) who wrote an alternative extension based on JSON-C implementation. A similar change was done by other Linux distributions, and this became the defacto standard for most Linux users.

The situation has recently changed with the acceptance of the Jakub Zelenka’s jsond RFC to replace the current non-free implementation with a free one. The change was committed to the code base on early February (Closing #63520) and expected to be released later this year as part of PHP7.


Filed under: Free software licenses, PHP
Categories: Elsewhere

Mike Hommey: Announcing git-cinnabar 0.1.1

Planet Debian - Fri, 13/03/2015 - 02:17

0.1.1 is a one-bugfix release fixing an issue where git-cinnabar could be confused if commands were started from a subdirectory of the repository. It might be the cause for corruptions leading to issues such as the impossibility to push.

If you do encounter failures please report them. Please also paste the output of git cinnabar fsck.

Categories: Elsewhere

John Goerzen: Suggestions for visiting the UK?

Planet Debian - Fri, 13/03/2015 - 02:14

My wife and I have been thinking of visiting the UK for awhile, and we’re finally starting to make some plans. I would be grateful to anyone reading this that might have some time to make suggestions on places to go, things to do, etc.

Here’s a bit of background, if it helps.

We have both traveled internationally before; this would actually be the first time either of us has visited another English-speaking country. We are content, and in fact would prefer, to venture outside the most popular touristy areas (though that doesn’t mean we’d want to miss something awesome just because it’s popular.)

We will have a little less than a week, most likely. That means staying on one area, or two at the most. Some other tidbits:

  • I particularly enjoy old buildings: churches, castles, cathedrals. A 400-year-old country church off a dusty road would be as interesting to me as Westminster Abbey — I’d consider both awesome to see. Castles that are in a good state of repair would also be great. I’d enjoy getting in the countryside as well.
  • My wife would enjoy literary connections: anything related to Dickens, A. A. Milne, Jane Austen, C. S. Lewis, etc.
  • Although I know London is full of amazing sights, and that is certainly one destination we’re considering, I am also fine with things like Roman ruines in Wales, A. A. Milne’s estate, country churches, sites in Scotland, etc.
  • Ireland / Northern Ireland might be a possibility, but we are mainly focused on Great Britain so far.
  • Would we be able to accomplish this without a car? I understand it is rather difficult for Americans to have to drive in the UK.
  • Are there non-conventional lodging options such as bed and breakfasts that might let us get to know our hosts a little better?
  • If it helps understand me better, some highlights from my past trips included the amazing feeling of stepping back in time at Marienkirche in Lübeck or the Museum in der Runden Ecke (a former Stasi building in Leipzig), exploring the old city of Rhodes, or becoming friends with a shop owner in Greece and attending an amateur radio club meeting with him.

Finally, we would probably not be able to go until September. Is that a reasonable time? Is part of September maybe less busy but still decent weather?

Thanks for any advice!

Categories: Elsewhere

Chen Hui Jing: Drupal 101: What I learnt from hours of troubleshooting Feeds

Planet Drupal - Fri, 13/03/2015 - 01:00

Feeds is a very useful module when it comes to importing content into your Drupal site. However, it’s not very forgiving, in that your data has to be formatted just right for the feed to take. This post will run through the basic feed importers and some key points I learnt from hours upon hours of troubleshooting. I’m pretty sure I’ve spent upwards of 50 hours dealing with feeds thus far in my life.

Before I begin, I have a short rant on the importance of content. You could skip directly to the bits on feeds but then, it’ll be less entertaining.

The heart of every website is its content. At least, most of the time. And as much...

Categories: Elsewhere

Joey Hess: 7drl 2015 day 6 must add more

Planet Debian - Fri, 13/03/2015 - 00:02

Last night I put up a telnet server and web interface to play a demo of scroll and send me playtester feedback, and I've gotten that almost solid today. Try it!

Today was a scramble to add more features to Scroll and fix bugs. The game still needs some balancing, and generally seems a little too hard, so added a couple more spells, and a powerup feature to make it easier.

Added a way to learn new spells. Added a display of spell inventory on 'i'. For that, I had to write a quick windowing system (20 lines of code).

Added a system for ill effects from eating particular letters. Interestingly, since such a letter is immediately digested, it doesn't prevent the worm from moving forwards. So, the ill effects can be worth it in some situations. Up to the player to decide.

I'm spending a lot of time now looking at letter frequency historgrams to decide which letter to use for a new feature. Since I've several times accidentially used the same letter for two different things (most amusingly, I assigned 'k' to a spell, forgetting it was movement), I refactored all the code to have a single charSet which defines every letter and what it's used for, be that movement, control, spell casting, or ill effects. I'd like to use that to further randomize which letters are used for spell components, out of a set that have around the same frequency. However, I doubt that I'll have time to do that.

In the final push tonight/tomorrow, I hope to add an additional kind of level or two, make the curses viewport scroll when necessary instead of crashing, and hopefully work on game balance/playtester feedback.

I've written ~2800 lines of code so far this week!

Categories: Elsewhere

Andrew Cater: Windows 8.1 / Debian 8 dual boot on Lenovo laptop

Planet Debian - Thu, 12/03/2015 - 23:16
Just proved this to be feasible on a new SSD. This was done using Windows bootable media and a Jessie netinst. The Debian netinst was copied onto a USB stick.

1. Switch  Secure Boot to "off" in BIOS / system settings

2. Set machine to UEFI boot.

3. Install Windows 8.1 to first part of the disk in a custom install. On a 128GB disk, I gave Windows 8.1 30GB.

4. Install Jessie from USB: allow Grub efi to install.

It does work and was a useful demonstration for a friend.
Categories: Elsewhere

Lunar: Paranoia, uh?

Planet Debian - Thu, 12/03/2015 - 23:08

A couple days ago The Intercept has released new documents provided by Edward Snowden. They show the efforts of the CIA to break the security of Apple plateforms.

One of the document introduces the Strawhorse program: Attacking the MacOS and iOS Software Development Kit:

(S//NF) Ken Thompson's gcc attack […] motivates the StrawMan work: what can be done of benefit to the US Intelligence Community (IC) if one can make an arbritrary modification to a system compiler […]? A (whacked) SDK can provide a subtle injection vector onto standalone developer networks, or it can modify any binary compiled by that SDK. In the past, we have watermarked binaries for attribution, used binaries as an exfiltration mechanism, and inserted Trojans into compiled binaries.

I knew it was a plausible hypothesis, but just reading it black on white gives me shivers.

Reproducible builds need to become the standard.

Categories: Elsewhere

Enrico Zini: crypttab-reuse-passwords

Planet Debian - Thu, 12/03/2015 - 22:45
Reuse passwords in /etc/crypttab

Today's scenario was a laptop with an SSD and a spinning disk, and the goal was to deploy a Debian system on it so that as many things as possible are encrypted.

My preferred option for it is to setup one big LUKS partition in each disk, and put a LVM2 Physical Volume inside each partition. At boot, the two LUKS partition are opened, their contents are assembled into a Volume Group, and I can have everything I want inside.

This has advantages:

  • if any of the disks breaks, the other can still be unlocked, and it should still be possible to access the LVs inside it
  • once boot has happened, any layout of LVs can be used with no further worries about encryption
  • I can use pvmove to move partitions at will between SSD and spinning disks, which means I can at anytime renegotiate the tradeoffs between speed and disk space.

However, by default this causes cryptsetup to ask for the password once for each LUKS partition, even if the passwords are the same.

Searching for ways to mitigate this gave me unsatisfactory results, like:

  • decrypt the first disk, and use a file inside it as the keyfile to decrypt the second one. But in this case if the first disk breaks, I also lose the data in the second disk.
  • reuse the LUKS session key for the first disk in the second one. Same problem as before.
  • put a detached LUKS header in /boot and use it for both disks, then make regular backups of /boot. It is an interesting option that I have not tried.

The solution that I found was something that did not show up in any of my search results, so I'm documenting it here:

# <target name> <source device> <key file> <options> ssd /dev/sda2 main luks,initramfs,discard,keyscript=decrypt_keyctl spin /dev/sdb1 main luks,initramfs,keyscript=decrypt_keyctl

This caches each password for 60 seconds, so that it can be reused to unlock other devices that use it. The documentation can be found at the beginning of /lib/cryptsetup/scripts/decrypt_keyctl, beware of the leopard™.

main is an arbitrary tag used to specify which devices use the same password.

This is also useful to work easily with multiple LUKS-on-LV setups:

# <target name> <source device> <key file> <options> home /dev/mapper/myvg-chome main luks,discard,keyscript=decrypt_keyctl backup /dev/mapper/myvg-cbackup main luks,discard,keyscript=decrypt_keyctl swap /dev/mapper/myvg-cswap main swap,discard,keyscript=decrypt_keyctl
Categories: Elsewhere

Bits from Debian: DebConf15: Call for Proposals

Planet Debian - Thu, 12/03/2015 - 22:20

The DebConf Content team is pleased to announce the Call for Proposals for the DebConf15 conference, to be held in Heidelberg, Germany from the 15th through the 22nd of August, 2015.

Submitting an Event

In order to submit an event, you must be registered as an attendee of DebConf15. If you have any questions about the registration process, please check the related information on the conference website.

Once registered, go to "Propose an event" and describe your proposal. Please note, events are not limited to traditional presentations or informal sessions (BoFs). We welcome submissions of tutorials, performances, art installations, debates, or any other format of event that you think would be beneficial to the Debian community.

Please include a short title, suitable for a compact schedule, and an engaging description of the event. You should use the field "Notes for Content Team" to provide us information such as additional speakers, scheduling restrictions, or any special requirements we should consider for your event.

Regular sessions may either be 20 or 45 minutes long (including time for questions) and will be followed by a 10 or 15 minutes break, respectively. Other kinds of sessions (like workshops) could have different durations. Please make sure to choose the most suitable duration for your event and justify any special requests.

Timeline

The first batch of accepted proposals will be announced in May. If you depend on having your proposal accepted in order to attend the conference, please submit it as soon as possible so that it can be considered during this first evaluation period.

All proposals must be submitted before June 15th, 2015 to be evaluated for the official schedule.

Topics and Tracks

Though we invite proposals on any Debian or FLOSS related subject, we will have some broad topics arranged as tracks for which we encourage people to submit proposals. The currently proposed list is:

  • Debian Packaging, Policy, and Infrastructure
  • Security, Safety, and Hacking
  • Debian System Administration, Automation and Orchestration
  • Containers and Cloud Computing with Debian
  • Debian Success Stories
  • Debian in the Social, Ethical, Legal, and Political Context
  • Blends, Subprojects, Derivatives, and Projects using Debian
  • Embedded Debian and Hardware-Level Systems

If you have ideas for further tracks, or would like to volunteer as a track coordinator, please contact content@debconf.org. In order for a track to take place during DebConf15, we must have received a sufficient amount of proposals on that specific theme. Track coordinators will play an important role in inviting people to submit events.

Video Coverage

Providing video of sessions amplifies DebConf achievements and is one of the conference goals. Unless speakers opt-out, official events will be streamed live over the Internet to promote remote participation. Recordings will be published later under the DebConf license, as well as presentation slides and papers whenever available.

Contact and Thanks to Sponsors

DebConf would not be possible without the generous support of all our sponsors, especially our platinum sponsor HP. DebConf15 is still accepting sponsors; if you are interested, please get in touch!

You are welcome to contact the Content Team with any concerns about your event, or with any ideas or questions ambout DebConf events in general. You can reach us at content@debconf.org.

We hope to see you all in Heidelberg!

Categories: Elsewhere

Drupal Easy: Florida DrupalCamp 2015 - It's SSSSuper

Planet Drupal - Thu, 12/03/2015 - 20:00

For the sixth year in a row, Central Florida will host the Sunshine State's largest gathering of Drupalists for two full days of learning, networking, and sharing at Florida DrupalCamp 2015. To be held Saturday and Sunday, April 11-12, 2015 at Florida Technical College in Orlando, approximately 300 people will gather for a full day of sessions and a full day of community contributions. Attendees will be provided with knowledge, food, and clothing - and maybe a surprise or two as well!

-->

read more

Categories: Elsewhere

Marko Lalic: solicit - an HTTP/2 Library for Rust

Planet Debian - Thu, 12/03/2015 - 18:55

For quite some time now, I've been following Rust, a new(ish) programming language by Mozilla. It's been around for a while, but recently it's been attracting a lot of buzz. Around the new year, I finally decided to take a deeper look into the language.

I find that the best way to learn a new programming language is to simply dive in and try to build something nontrivial. At that point I'd also been interested in learning more about the specifics behind the new HTTP/2 spec, so I decided to combine the two... The result is a (work in progress) client library for HTTP/2 written in Rust, which can be found at this GitHub repository: https://github.com/mlalic/solicit

What follows is a description of what I aim to achieve with the library, as well as an overview of its current design. If that doesn't interest you, you can just check out the GitHub repo for some examples or the source code itself.

Goals

Given that there are already some fairly popular HTTP libraries for Rust (hyper leading the way), I decided that I wouldn't aim to replace them. Rather, the idea is to focus on the lower levels of the HTTP/2 protocol—what is essentially another transport protocol—and expose an API that allows those libraries to use an HTTP/2 connection to send requests and receive responses. HTTP/2 doesn't change the semantics of the protocol, so once any HTTP/1.1 library gets the raw headers and body, it should be able to represent the response regardless of the fact that it came on an HTTP/2 connection. The same holds for sending requests: only the representation of the request changes, not its content.

There are some minor differences, such as HTTP/2 doing away with the reason phrases being part of the response, but those were only meant to be human readable and "MUST NOT" have had any influence on the semantics of the response.

Therefore, the primary goal for the library is to provide an API for using an HTTP/2 connection on the lowest level, but making it easy for clients to customize or augment any particular step of handling a response, without having to know the details of functionality below the layer they want to customize.

As an example, if one wanted to build a client that sends out progress notifications for downloads, it wouldn't be good if they needed to muck about with raw HTTP/2 frames—ideally, they'd only need to implement a new way to handle incoming data chunks for streams. The same applies for implementing a client that streams the download into a file (instead of saving it in memory) or one that sends the chunks to a different component for processing as soon as they're received (e.g. parsing HTML).

Since the Rust standard library only exposes blocking IO primitives, I decided to base this library on blocking IO, as well. However, the goal was to make it flexible enough so that clients that would like to allow multiple requests to be sent concurrently on the same HTTP/2 connection can be built, but without the library itself spawning any threads.

Finally, on a less conceptual level (and more of an implementation level), the code should have extensive test coverage.

Design

The library is split into several layers, each of which provides services to the one above it. A brief description of each layer follows.

Transport Layer

This layer provides the API for raw byte stream communication with the peer.

Essentially, it's a wrapper around the particular transport protocol that is used for the HTTP/2 connection. As the HTTP/2 spec allows the transport protocol to be either a cleartext TCP connection or a TLS-protected one, those are the ones that need to be implemented at this level.

The API of the layer is represented by a single trait TransportStream that simply requires io::Read and io::Write to be implemented and (for now) provides a single convenience method based on the underlying io::Read implementation.

For a clear-text TCP connection, the only thing that was required to implement it was one line of code:

impl TransportStream for TcpStream {}
HTTP/2 Connection Layer

The connection layer provides an API for reading and writing to a raw HTTP/2 connection. This means reading and writing HTTP/2 frames, not arbitrary bytes.

Each HTTP/2 frame has to follow the same basic structure(a 9-byte header followed by a sequence of byte representing the payload of the frame). This is represented by the RawFramestruct.

Each HTTP/2 frame type can have its own specific format for the content of the payload and assign meaning to the flags found in the header. Therefore, each frame needs to have its own implementation that can parse a RawFrame or return an error if the raw frame does not represent a valid frame of that type. Some common methods that each frame type implementation needs to support are given by the Frametrait that must be implemented by the implementations.

Finally, the HttpConnectionstruct handles reading the byte stream from the underlying TransportStream instance, correctly delineating frames and parsing them into the appropriate frame type implementation (by delegating to the correct Frame implementation based on the frame type found in the header).

Obviously, varying the implementation of the transport layer is a matter of choosing the appropriate TransportStream implementation. This includes using mock implementations for testing the HttpConnection itself.

HTTP/2 Client Connection

The ClientConnectionbuilds upon the HttpConnection by using it to expose functionality that is specific to the client side of an HTTP/2 connection. This includes sending requests and reading responses. The struct takes care of creating frames that need to be sent for a given request (including HPACK header encoding) and shipping them off to the server (using the underlying HttpConnection instance).

As for handling a response, the ClientConnection expects to get an instance of a struct implementing the Sessiontrait when constructed. This trait essentially defines a number of callbacks: methods that will be called on this instance when the corresponding event occurs in the ClientConnection.

Therefore, the ClientConnection understands the semantics of the particular frames that it reads (e.g. performs the decoding of the HEADERS frames' payloads, passing the raw data received in a DATA frame to the session, etc.). However, it does not know anything about streams; it only passes the stream ID up to the session layer, without thinking about whether the stream is open, valid, etc.

HTTP/2 Session

As mentioned in the previous section, each ClientConnection requires an instance of a struct implementing the Sessiontrait to be passed to it at construction time.

The Session trait defines a number of callbacks that are invoked in the appropriate moments during the processing of frames read on a client connection. For example, new_headers (takes a list of heaers and a stream on which they were received) or new_data_chunk (a buffer and a stream on which the data arrived).

The session is in charge of handling these events as they arise. It is up to it to decide what (if anything) should be done with the data that it receives.

There is a default implementation of the Session trait (unimaginatively named DefaultSession), which provides an implementation that tracks which streams are currently open and delegates the processing of new events on particular streams to instances of a Streamtrait.

This allows for client implementations to simply vary the implementation of a Stream that they provide to the DefaultSession in order to change how a particular part of a response is handled, but let the DefaultSession take care of tracking which streams are open and valid.

Different implementations of a Session still can exist, if the particular client needs more fine-grained customization over how these events are handled, but for most purposes the default session, along with Stream customization should probably be enough.

HTTP/2 Stream

Again, as mentioned previously, the DefaultSessionimplementation of the Session trait relies on a Streamtrait providing the handling for events arising on individual streams.

This level should be the one that gets customized most often in alternate implementations.

A default stream implementation—DefaultStreamhandles the messages by building up a response in-memory. Different implementations could instead send progress notifications on an associated channel, for instance.

HTTP/2 Client

The final layeris that of a client that exposes methods that would usually be expected for a client HTTP library: sending requests, obtaining responses. This layer is not the primary focus, though, and it only exposes two simple implementations that showcase how the lower level APIs can be used to build a client. The second purpose it fulfills is as a "sanity check" that the APIs actually do allow the goals to be met.

Therefore, one of the clients allows for requests to be sent from concurrently running threads and the responses to those requests to be obtained asynchronously (in the form of a Future<Response>). However, the responses are basic and very raw: they are stored fully in memory (not available until they've been read until the end) and both the body, as well as the headers, exposed as raw byte sequences.

As an example how this clientcan be used (as well as the simpler single-threaded version), check out the Examplessection in the GitHub repository's README file.

Future Work Refactoring APIs

As the project was started as a Rust learning exercise, the initial APIs are slightly awkward and fairly inefficient to work with. For example, the solicit::hpackmodule requires headers to be represented as a tuple of Vec<u8>, which means that whenever we need to encode a header list, even though their values might be (statically known) byte sequence literals, such as (b":method", b"GET"), we need to make a bunch of to_vec calls on the &[u8]s before passing them to the encoder, leading not only to a really ugly and tedious way of obtaining the encoded representation of the headers, but also to a lot of unnecessary allocations.

Another API that will see some refactoring and improvement is the TransportStream, as well as the HttpConnection in order to make it possible to have separate threads perform reads and writes on the connection. Currently, the socket is owned by the HttpConnection instance and all writes and reads require a &mut reference, making this impossible. This change would tackle this by embracing Rust's new try_clone method on the TcpStream into the TransportStream and refactoring the HttpConnection to allow splitting it into a write and read handle.

HTTP/2 Features

As already mentioned, only a small subset of the full HTTP/2 spec is currently implemented, so, obviously, implementing the rest of it falls under the most important future work.

Some near- to mid-term priorities that will be tackled are:

  • TLS-backed connections: a new TransportStream implementation that wraps a TCP socket into a TLS wrapper. This will probably rely on OpenSSL bindings.
  • Support for all HTTP/2 frames: only the three vital frames are implemented so far; other frames are a prerequisite to implementing properly closing streams, handling closed streams etc.
  • Signaling stream- and connection-level errors to the peer
  • Flow control: right now this aspect is completely ignored
  • Server push: the idea is that multithreaded clients could handle pushed responses as soon as they arive, whereas single-threaded ones would be allowed to fetch a list of them every so often.

Obviously, those aren't all the features of HTTP/2, but it's a rough list of things I'm planning on working on myself as the next steps.

Integration With an (existing?) HTTP Library

I would like it if in the end the library or at least some of its pieces ended up being used in the scope of one of the fully featured HTTP libraries. If there's any interest in this, I wouldn't mind putting in some extra legwork to help make it happen.

Conclusion

While I'm certain that there can be better, more efficient, more elegant implementations, I've had a lot of fun working on this so far (learning new things is always fun!) and if nothing else I'll continue in order to gain the deepest possible understanding of HTTP/2. For anyone that might have read all the way through, thanks for reading and I'm open for any sort of feedback!

Categories: Elsewhere

Cheeky Monkey Media: Importing and Exporting Databases with Drush

Planet Drupal - Thu, 12/03/2015 - 18:25

A few weeks ago, I was pulled into a Non-Drupal project. As I was configuring the site to run on my local computer, I realized that I have been taking advantage of Drupal and Drush. I forgot how easy it was to import and export MYSQL databases. If you're a drupal developer and are not using drush to import and export your databases, you should. It will save you time, and its easy.

Configure Settings.php

Before you attempt to import a new database, make sure you have the database configurations setup properly in settings.php. If you don't have this specified, drush...Read More

Categories: Elsewhere

Jonathan Dowland: R.I.P. Terry Pratchett

Planet Debian - Thu, 12/03/2015 - 17:15

Pratchett and I, around 1998

Terry Pratchett dies, aged 66.

It looks like his last novel will be The Long Utopia, the fourth book in the Long Earth series, co-written with Stephen Baxter.

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator - Elsewhere