It's very easy to make, and just in case the local hoodlums smashed your pumpkins to bits this year, there are some instructions for using canned pumpkin instead of the fresh stuff.
(UPDATE: if the pumpkins have been all carved up and sitting in front of your house for a while, please consider throwing them out and using canned pumpkins in the recipe. I'm not sure that you should try to eat anything that's been rotting away outside for any length of time, no matter how you cook it.)
I chuckled when I read the article, because I had been playing around with exactly the same technique about 2 weeks ago. Weird. It's like we were living parallel lives or something...
Anyway, even if you don't subscribe to the magazine, you can download a sample database that has the relevant code from the article link above. It's a pretty nice way to add something like a logo to a rich text field (perhaps for mailing). Or maybe a graph you dynamically created and exported to a temporary file using something like JGraph or JFreeChart.
The short description is that it's a Java library that uses Apache SOAP and WSDL4J to provide a very easy to use interface for calling RPC-based SOAP web services. Click the download link above and read through the docs for lots more information.
The long description... Well...
I've noticed in a lot of languages that there are libraries available that make it very easy to call certain types of web services. In particular, RPC/encoded services are a piece of cake, because all the namespace and type information is easily accessible and can be interpolated by the program, not the programmer.
For example, using the Microsoft SOAP Toolkit, you see calls that look like this:
Set client = CreateObject("MSSOAP.SOAPClient")
result = client.methodName("param1Value")
With Python, the calls are like:
from SOAPpy import SOAPProxy
server = SOAPProxy('http://wsdlfile')
result = server.methodName('param1Value')
And with PHP nuSoap, the calls are like:
$client = new soapclient('http://wsdlfile');
$response = $client->call('methodName', array('param1Name' => 'param1Value'));
Granted, in certain cases you had to do some things with namespaces and SOAPActions and whatnot, and complex data types required a little work, but a lot of times it was that simple. No knowledge of WSDL or XML schemas or anything. Just point to a WSDL file and call the method.
In Java, none of the examples seemed so simple. Tools like Apache Axis and JAX-RPC rely on pre-processing the WSDL files and generating "stub" classes -- which made the calls fairly easy but which wasn't dynamic and which required a lot of work up-front. WSIF was a lot closer (and honestly might be what I end up using), but there were still a few steps if you got beyond the simple DynamicInvoker examples, and I had trouble getting good debugging info.
SoapHelper sh = new SoapHelper("http://wsdlfile");
Object response = sh.callSimpleMethod("methodName", "param1Value");
It figures out the namespaces and parameter names and everything for you, complex data types can be easily added with another single call, and complex responses can be treated as plain XML if you don't want to bother modelling them in advance with a Java class. And I added a few debug things that allow you to see the raw message and response, for the times when that's important.
I'm still having problems with document/literal web services, but if everything keeps working I'll figure that out too.
The other nice thing is that I can use the jurst library and calls natively in a Notes 7 client, as long as I include Apache SOAP somewhere (like as a resource in a shared script library). So it's a fast, portable way of calling and testing the web services I'm playing around with in Domino 7.
Whew, lots of writing. That's enough information for now. I'll probably be finished with my sample Notes 7 database for you to play with in a few days (sorry, no workee in Notes 6.x).
It was interesting on a few levels. From the engineering standpoint, for example, I kind of thought they had this whole bra thing figured out. Apparently not, since there's so much ongoing research in this area. Maybe as a man, I just don't appreciate the problem. In fact, that's probably the case. As the article points out:
A pair of D-cup breasts weighs between 15 and 23 pounds -- the equivalent of carrying around two small turkeys.
Okay, small turkeys. That's something I can get my head around. I never thought about it quite like that before. I can feel my empathy growing.
One thing that shocked (yes shocked) me though, was this part of the article:
Bra designers begin with a significant handicap: The structure of breasts is still something of a mystery. Evolutionary biologists aren't sure why breasts evolved as they did -- chimpanzees and other mammals develop them only when lactating -- and no one knows what keeps them from sagging. An individual breast is made up of between 15 and 20 sections, known as lobes. These are composed of smaller lobules that end in bulbs that produce milk and are interconnected by a network of ducts. But breasts contain no muscles at all, and the bulbs and ducts are essentially the same in all women. Size is mainly determined by how much fat the breasts contain. Most anatomists believe the breasts' primary means of support are the Cooper's ligaments interlaced among the lobules. But others give the skin more credit.
I just don't get that at all: "no one knows what keeps them from sagging"?!? They can send a man to the moon, but they don't know what keeps breasts from sagging? That seems crazy to me. I mean, it just seems like such a straightforward thing to study. And a problem that a number of scientists would be banging down the doors to... um, get their hands on, so to speak.
I dunno, maybe the reporter was just talking to the wrong people. I've got to think that someone has that figured out.
Then when I started Notes back up, I got the "Lotus Notes is not your default mail client" message. Huh, for some reason running the latest Office service pack reset my default mail client to... well, I guess I can't be certain because I didn't check before I clicked "Yes" to reset Notes as my default, but it changed it to something else. Not sure if that's normal.
And then I get to the "Enabling your existing applications for event reporting" section, with the following code:
Dim session As New NotesSession
Dim log As NotesLog
Set log = session.CreateLog("")
Call log.LogEvent("A custom event!", "EventDispatcher", EV_MAIL, SEV_FATAL)
So all I have to do is call LogEvent and use the super-special "EventDispatcher" queue, and my LotusScript/Java agents can send messages to DDM, huh? Cool. So simple.
But then there's this whole thing about how DDM can actually monitor pre-ND7 servers for "simple" events, which makes it sound like DDM is listening on the "EventDispatcher" queue, and this might actually be some legacy thing that's already in use.
Enter Thomas Gumz -- Redbook author, IBM über-developer, and man about town -- who tells me that this is the same queue that the old Events4.nsf database listens for, and who also mentions that a peek into the Domino Web Administration database will confirm that this queue has been alive for a few versions of Notes already.
So I pulled out my DDSearch tool (also written by the venerable Mr. Gumz) and took a little look. "EventDispatcher" is aliased by the global EVENT_QUEUE_NAME variable, which is used in the LogEvent sub as:
'log to the events task
'if the event task is not running on the server we'd get an "no such queue name" error
On Error Resume Next
Call m_eventlog.LogEvent(EVENT_PREFIX & " " & hsMessage, EVENT_QUEUE_NAME, hiType, hiSeverity)
There we have it: logging to Events4.nsf (see clarification below) with a simple call to NotesLog.LogEvent. As long as you know the magic queue name, you're there. And since DDM will also listen for that queue, you can amaze your friends with code that is already forwards-compatible with Notes/Domino 7.
This functionality will, of course, be in an upcoming version of the OpenLog database. It's due for a few updates anyway.
UPDATE: comments seem to be broken again, so Thomas e-mailed me the following clarification:
Nothing gets 'logged to events4.nsf' or 'ddm.nsf' really. Events4.nsf is a configuration db, which the 'Event Monitor' server addin task reads from. Not writes to.
That event monitor task basically 'watches' for events occuring on the server, writes events which are configured to be logged to a db (usually STATREP.NSF), or calls/executes event handlers (like 'send me email if this event xyz occurred'). Additionally in R7, it also executes and manages most of the new DDM probes, which in turn also raise (new) events, which then also go into DDM.NSF.
I took a look at the database design, and it wasn't anything new. It was just a good use of a feature that's been around since at least Notes 6. See below:
They just used an image for the table border, and the image they chose was an image of a rounded table (of all things). In the case of a solid-color rounded table, you just have to make sure the color of the table cells is exactly the same as the color of the image, but otherwise it's pretty straightforward. You could even have just a table border around white table cells, I would guess.
What's also interesting about this technique is that Notes seems to stretch the table borders out for you, so the image you use for the rounded table doesn't have to be exactly the same size or proportion as the Notes table you end up with. Everything resizes for you automatically.
p.s. -- I'm sure about a dozen people are reading this, saying "Yeah, well I've been doing this since R5. Nyah nyah. That is so last millenium." Whatever. This was new to me.
Also, and this has nothing to do with Serenity but it's also SciFi-related, the second installment of the NYC2123 online/PSP comic is out. The black and white comic art is interesting, although I have no idea where the story is going right now.