No, the resource fork is dead for good reasons. (1) The resource fork is fragile and easily corrupted, like the Windows registry in the bad old days. (2) Four-character namespaces suck. (3) 24 MB limits suck. (4) Extended attributes and bundles are better in every conceivable way.
The resource fork was designed for a different world. (A) In the old days, there was a blurry line between OS and app, so there was no reason to make the resource fork "opaque". Without opacity, there is no graceful way to use it in a preemptive multitasking environment. (B) In the old days, pointers were 24 bits. The high 8 bits didn't go anywhere, so people used these high bits to store extra data. Resource forks make use of 24-bit quantities for this reason — which went out of favor when Macs with the 68020 were introduced in 1987. (C) The real feature of resource forks was to reduce the disk space usage and load times when you have lots of small pieces of data, but — data is bigger and we have better archive formats.
So yeah, extended attributes are the way to go.