For those who follow my crafty pursuits, I've just posted pictures in the gallery of the mini-quilt I finished this weekend. Well it's more of a wall hanging made with quilting (no piecing).
Also if you saw the Butterfly Quilt for Ally, posted earlier on the gallery, well everybody loves it and wants to be my niece too. I don't have an opinion from my real niece (she's only one year old, after all, and extraordinarily easily bored) but her parents love the quilt. Whoo hoo!
Sunday, November 27, 2005
Saturday, November 26, 2005
It's been a busy few weeks, which is why I'm only now posting about another IETF meeting although it happened Nov 7. The meeting was the XML-PATCH-OPS BOF, and here are the official minutes.
The SIMPLE WG has been working on some HTTP extensions and using XML in order to allow instant messaging clients to interoperably edit buddy lists (stored on the IM server) and other configuration data. Special functionality to modify/retrieve XML stored on an HTTP server is rampant these days, so it seemed like a good idea to consider general mechanisms, rather than only design mechanisms limited to SIMPLE use cases. So Jari Urpalainen has been working on a general XML diff, or patch algorithm -- like Unix diff files, only specialized for XML (operations that can add or remove branches from the XML tree structure, rather than operations on lines as in text diffs).
Once the SIMPLE WG was potentially working on such general mechanisms, it seemed like a good idea to hold a BOF (Birds Of a Feather) meeting to see if there were general use cases and find or identify other potential IETF participants. Some places where we thought we'd see interest:
to form a separate effort. So the work proceeds on the SIMPLE mailing list. Still, I plan to keep up with Jari's work and possibly help him generalize it further -- for example, we may add the ability to make changes to text values of XML elements without replacing the entire text value.
Note that there exist other XML diff formats, but none of them are standardized. Microsoft's got one, the W3C has tackled this both for rdf and more generally (though the W3C didn't have any guidance for the IETF when we asked about this BOF), and it's been the subject of several theses: treepatch, diffxml and a survey.
The SIMPLE WG has been working on some HTTP extensions and using XML in order to allow instant messaging clients to interoperably edit buddy lists (stored on the IM server) and other configuration data. Special functionality to modify/retrieve XML stored on an HTTP server is rampant these days, so it seemed like a good idea to consider general mechanisms, rather than only design mechanisms limited to SIMPLE use cases. So Jari Urpalainen has been working on a general XML diff, or patch algorithm -- like Unix diff files, only specialized for XML (operations that can add or remove branches from the XML tree structure, rather than operations on lines as in text diffs).
Once the SIMPLE WG was potentially working on such general mechanisms, it seemed like a good idea to hold a BOF (Birds Of a Feather) meeting to see if there were general use cases and find or identify other potential IETF participants. Some places where we thought we'd see interest:
- WebDAV allows authors to collaborate on documents stored on HTTP servers. Sometimes these documents are quite large and it would be useful to be able to upload changes without sending the entire file again. In fact, Adobe engineers have talked to me about this -- some of their WebDAV functionality is intentionally designed to limit the number of times large files are exchanged between client and server, so that the user isn't constantly waiting for slow uploads or downloads. Obviously an XML patch format only works if the document is in XML, but some Adobe tools do support XML formats (e.g. InDesign). Another piece to this puzzle is the HTTP PATCH operation I've proposed, an idea I intend to come back to shortly particularly if I get any help (hint, hint).
- The NETCONF WG is pursuing ways to interoperably configure network devices and has also settled on using XML and HTTP. They've got very similar problems of wanting to make small changes to large data sets.
- Large Web pages in XHTML could be edited using an XML diff format to upload only changes.
- Large Web pages in XHTML could be downloaded faster using RFC3229 and an XML diff format. A text diff is used today but an XML diff format could be even more efficient, particularly for...
- Blog feeds. Today, a blog feed can be a large XML file, in Atom or RSS format. Today, if the ETag or Last-Modified timestamp of the blog feed changes, the newsreader client downloads the entire file. Similarly, to add a single new post to the feed, blog editing tools may have to upload a new feed file (unless the server does this magically somehow). This is really just a special case of the general "large files being shared" case, but since blogging generates so much traffic it seemed worth mentioning.
to form a separate effort. So the work proceeds on the SIMPLE mailing list. Still, I plan to keep up with Jari's work and possibly help him generalize it further -- for example, we may add the ability to make changes to text values of XML elements without replacing the entire text value.
Note that there exist other XML diff formats, but none of them are standardized. Microsoft's got one, the W3C has tackled this both for rdf and more generally (though the W3C didn't have any guidance for the IETF when we asked about this BOF), and it's been the subject of several theses: treepatch, diffxml and a survey.
Tuesday, November 15, 2005
In the past the IETF tried to discuss in a green-field manner how to internationalize email addresses and other email headers. None of the many options seemed really low-risk, however, and those discussions didn't get very far -- rat-holes being very frequent, and people having very different notions about what a solution could look like and what the outcomes and side effects might be.
The BOF I attended last week, however, was much more focused: it was about whether or not the IETF should charter a group to work on a specific experimental solution for internationalizing email addresses as outlined in several draft documents. That solution focuses on SMTP, so that "consenting adults" in an environment that wants to do i18n addresses may do so, and SMTP agents have a reasonable way to deal with these addresses when communicating to the wider world. It's a somewhat transitional approach, acknowledging that existing Mail User Agents (MUAs) and Mail Transport Agents (MTAs) won't immediately be able to handle these.
The discussion was mostly abour risks and unknowns. Some of the risks:
Normally the IETF is rather risk averse when there are so many unknowns, particularly when 'Net fragmentation might occur. In the past the IETF has gone around and around trying to get more certainty before even chartering a working group. This time, however, since there have been so many discussions and stalled related efforts before, the attendees took a leap into the unknown and approved the working group -- unanimously, I believe. Imagine Admiral Farragut's sailors taking a "hum" and deciding together to damn the torpedoes.
The BOF I attended last week, however, was much more focused: it was about whether or not the IETF should charter a group to work on a specific experimental solution for internationalizing email addresses as outlined in several draft documents. That solution focuses on SMTP, so that "consenting adults" in an environment that wants to do i18n addresses may do so, and SMTP agents have a reasonable way to deal with these addresses when communicating to the wider world. It's a somewhat transitional approach, acknowledging that existing Mail User Agents (MUAs) and Mail Transport Agents (MTAs) won't immediately be able to handle these.
The discussion was mostly abour risks and unknowns. Some of the risks:
- It's not known how (and when, and by whom) IMAP would be updated to handle i18n addresses, and how clean that could be.
- It's not known how POP would be updated to handle i18n addresses (Chris Newman stepped into the line of fire here)
- It could be difficult to manage VCards, iCalendar objects, and Web pages where mailto URLs and email addresses appear. Some of these support i18n, some don't; even ones that do may have incompatible representations.
- Although i18n addresses are supposed to remain within these groups of consenting adults and be transformed before transmission to non-i18n MTAs, it's not known to what extent these would actually leak out.
- When these do leak out, the user experience of email users with non-i18n MUAs could be unsatisfactory.
- There will probably be serious difficulties when non-i18n MUAs are used to try address mail with i18n addresses -- it's possible that sometimes only an i18n address is known and the user can't figure out how to enter it or isn't allowed to by their software.
Normally the IETF is rather risk averse when there are so many unknowns, particularly when 'Net fragmentation might occur. In the past the IETF has gone around and around trying to get more certainty before even chartering a working group. This time, however, since there have been so many discussions and stalled related efforts before, the attendees took a leap into the unknown and approved the working group -- unanimously, I believe. Imagine Admiral Farragut's sailors taking a "hum" and deciding together to damn the torpedoes.
Tuesday, November 01, 2005
"Eye of Newt" Jello shots
Although it's been pointed out to me that doing jello shots at parties is more of a twenty-something activity than thirty-something, I don't care. I never did jello shots before so dammit, at our party this past weekend, I was determined to do jello shots.
The ostensible excuse was the Hallowe'en theme: orange jello shots with black "eye of newt" in the bottom. I used black tapioca pearls, the kind that are served in "pearl tea" which I love. I found packages of dried black pearls in an Asian grocery store and this worked well.
Although it's been pointed out to me that doing jello shots at parties is more of a twenty-something activity than thirty-something, I don't care. I never did jello shots before so dammit, at our party this past weekend, I was determined to do jello shots.
The ostensible excuse was the Hallowe'en theme: orange jello shots with black "eye of newt" in the bottom. I used black tapioca pearls, the kind that are served in "pearl tea" which I love. I found packages of dried black pearls in an Asian grocery store and this worked well.
1 large package orange jello
2 c. boiling water
1 c. mandarin vodka (or other clear liquor)
1 c. cold water
1 pkg tapioca pearls (five servings)
Boil tapioca pearls -- I found it took longer than the advertised 5 minutes. Drain and rinse and distribute into little paper Dixie cups (I used about 20 but these were smallish shots). Mix boiling water and jello powder to dissolve then add liquor and cold water. Pour mixture into cups and put into the fridge for about an hour.
The paper cups are important because you have to squish the jello shot out into your mouth. Leaving the jello solid too long before serving means that the pearls get harder so don't prepare too far in advance.
Subscribe to:
Posts (Atom)
