Monday, March 31, 2008

IPv4/v6 Regular Expressions

I found these useful regexes in my notes. I probably found this somewhere on the Internet, but I forgot where.

IPv4 address

^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$

IPv6 address

^[0-9a-fA-F]{1,4}(\:[0-9a-fA-F]{1,4}){7}$

Note that this does not work with shortened form such as dead::beef. dead:0000:0000:0000:0000:0000:0000:beef must be used instead.

Thursday, March 20, 2008

dnsmasq: unknown interface xennet0

As of version 2.41, dnsmasq doesn't support Xen virtual network interfaces in NetBSD. This means that running dnsmasq inside a Xen domU results in the following error:

dnsmasq: unknown interface xennet0

Uberlord made a patch just a few moments ago:
- http://roy.marples.name/~roy/dnsmasq-netbsd.patch
- http://roy.marples.name/~roy/dnsmasq-bridge.patch

The beauty of Open Source... =)

Tuesday, March 18, 2008

Permission denied to call method XMLHttpRequest.open

Problem
When deploying DHTML OpenLaszlo applications in SOLO mode, attempts to fetch datasets results in the following error:

ERROR: uncaught exception: Permission denied to call method XMLHttpRequest.openLFCdhtml-debug.js (line 1421)
uncaught exception: Permission denied to call method XMLHttpRequest.open

Solution
As a security measure, most browsers restrict XMLHttpRequest such that they don't accept XML data if the HTTP response headers are not properly set. To fix this, simply change Content-Type to:
Content-Type: application/xml; charset=UTF-8

Monday, March 17, 2008

xen Error: Device 2050 (vbd) could not be connected. Backend device not found.

Problem
NetBSD dom0 is unable to launch more domUs. Attempting to launch more domUs results in the following error:
xen Error: Device 2050 (vbd) could not be connected. Backend device not found.
Solution
The system ran out of loop devices. Create more vnode disks using the following command:
/dev/MAKEDEV vnd1
/dev/MAKEDEV vnd2
...and so on

Friday, March 14, 2008

__LZgetNodes: p is null in Datapath

I'm creating an IPv4/IPv6 OpenLaszlo widget that can bind to a datapath. I spent hours trying to find out why this.datapath.getNodeText() doesn't work inside <handler name="oninit">, although it works fine inside <method>. I kept getting an error of "p is null in Datapath."

For developers experiencing a similar problem, you might want to check out Laszlonia's entry on his blog. It turns out that I simply had to use <handler name="ondata">.

Tuesday, March 11, 2008

map methods execute*() methods in Agavi

Agavi is architecturally beautiful. I can really appreciate the way they designed this thing. One fundamental problem with this framework, however, is that it lacks good documentation. You need to read the code, or ask others who already did, for you to answer some very simple questions.

In my case, I was looking for a way to change the HTTP verb mappings with AgaviWebRequest methods.

Agavi maps executeCreate() with HTTP PUT and executeWrite() with HTTP POST. If I use these functions in the context of REST architecture, it makes more sense if they are mapped the other way around. Although I understand that there is no single way to implement REST, there seems to be a general agreement that update operations should be mapped to HTTP PUT while create operations should be mapped to HTTP POST.

Fortunately, Agavi provides a simple (undocumented) way to change the mappings. In config/factories.xml, simply add:
              <request class="AgaviWebRequest">
<parameter name="method_names">
<parameter name="POST">create<parameter>
<parameter name="GET">read<parameter>
<parameter name="PUT">write<parameter>
<parameter name="DELETE">delete<parameter>
<parameter>
<request>
Thanks to the crazy guy, MikeSeth. =)

Friday, March 07, 2008

confused on implementing REST using HTTP PUT

I'm implementing a REST web service using PHP5 right now. I'm a bit confused on how to implement a write operation using HTTP PUT verb.

In PHP, data that are sent via HTTP POST are in the following format:
variable1=data&variable2=data
The data is immediately available via $_POST. Data that is sent via HTTP PUT is uploaded as a file to the server and must be parsed before reading. There's nothing wrong with it per se, except that writing data is inconsistent. There's no problem requiring my REST clients to upload a file using HTTP PUT, except that it's inconsistent.

So far, I used curl for testing my web app. I haven't tried sending data via <form> using a web browser, and I don't know whether <form method="put"> works. If it does, then the browser would probably send the data similar to POST's format, with only a different header (UPDATE - 2008/03/11: yepp, it indeed works that way). Blah, possibilities, possibilities.

I'm using Agavi framework, by the way. It's a kick-ass lightweight framework. Agavi is beautiful, but the documentation is sparse. Documentation effort is underway, and I hope to see more of it in the coming weeks. Without it, Agavi is considered "fringe" at the moment (I like fringe software; I even use fringe operating systems such as *BSD hehe).

cvsmode in csup

Nice, there are now patches for CVSMode support in csup: http://people.freebsd.org/~lulf/patches/csup/cvsmode/. This means that csup can now fetch complete CVS repositories. Thank you Ulf, whoever you are!