January 2008 - Posts
you'd think there'd have been an accountant or a production manager on staff there. it's a simple counting problem. something they want the kids to learn, maybe ?
From: service@laptopgiving.org
Sent: 2008.01.31 01:48:35 Eastern Standard Time
Subj: Update On Your XO Laptop
Dear C,
Please accept my apologies for the delay in receiving your XO laptop. Give One Get One was such a phenomenal success that we over-taxed our order processing and payment systems. Demand exceeded supply. Additional XO laptops are being built now and will be delivered in 45 to 60 days. If you wish to reconsider your contribution in the face of this delay, we will issue a refund to you. We have set up a dedicated phone line for these requests. The number is 1-800-883-8102.
In the meanwhile, please know that laptops are in the process of going to Mongolia, Cambodia, Afghanistan, Rwanda and Haiti as part of the "give one" side of the equation. Fortunately, OLPC's mission of getting laptops to the children in these countries has not been delayed. In Mongolia , the children are already enjoying themselves and learning new things with their XO laptops. Please see: http://wiki.laptop.org/go/Ulaanbaatar. Eliminating poverty through learning is gaining wider acceptance thanks to support like yours.
Sincerely, 
Nicholas Negroponte
Chairman
OLPC Foundation 
well, ok, i guess i have also donated my patience so that they can learn these things and improve their performance on their mission elsewhere. think of what may have occurred if they had not had this kind of visible experience. or, are things really just as bad, yet unpublicized, with their core program ?
so anyway, i don't expect much of an update on this until march / april.
on the bright side, being rushed into the donation / purchase in the first place was undesirable. didn't give any chance for bugs to be worked out of the system, etc. but that was the only purchase period available. now, this delay should mean that fixes will have had a chance to have found their way into the hardware & software, meaning more reliable boxes. just a chance.
this was kind of my original expectation, delivery in the spring, whenever they got around to it. they should have stated those uncertainties a bit more strongly for some people, instead of getting strong-armed into the over-promising game. i suppose i'm used to reading between those lines. i was surprised at the earlier emails making noises about a january delivery.
there's something to be learned here for everyone, but especially in the software profession: stick to your realistic estimates. giving in to customers who can't face reality won't change reality.
resolved the following issues from earlier, one way or another:
- a number of my .xsl's use msxml extensions
"solution": use the element-available() function and just strategically ignore the ie specific processing. i'm not entirely happy with this, but it's the only reasonable option until xslt 2.0 gets implemented. i did manage to change a couple of minor items to use only core xpath functions (notably, the apod display).
- ie can allow cross-domain access, but ff cannot
i did create the proxy i mentioned, and it was as simple as i thought. i added 15 minute caching while i was at it. one snag: the proxy piece is accessed in a sub-application from community server's perspective, when used in my weblog. had to add
<location path="." inheritInChildApplications="false">
...
</location>
around the main system.web section in community server's web.config to prevent undesired inheritance in the sub-app.
- handling of xml data islands in ff
ff has a problem properly constructing the dom when empty nodes are present. adding fixes these sorts of things. this affects a lot of stuff in ff, especially when dealing with css.
anyway, doing this turns out to make the processing easier than in ie, since i only had to get the childNodes property. of course, walking the nodes in ff meeans checking for and excluding text etc. *sigh*
one remaining annoying issue is that mozilla xsl handling does not support the disable-output-escaping attribute. so yes, you're seeing markup. ff also does some strange things when accessing rss files directly. it has special processing in place that is not overrideable, and it implements this with a series of extensions in javascript.
yeah, ok, these open source folks are pissing me off. they are as bad or worse than ms when it comes to doing - or not doing - shit, according to their whims. and usually, it results in crippled-ness, whereas when ms decides not to abide by standards, it's usually in the cause of usability. those people blindly praising ff etc. don't have a clue.
another issue: i render those feeds with a "refresh" link that's supposed to just reload & display the feed its assocaited with. for some reason, in ff it's reloading the enitre page. whatever.
still to-do: all the sub-pages of the site.
an oh yeah: for some reason, just as i was getting to the end of all this, ff started to regularly lock up on me. even after a reboot, same problem. not sure what introduced this issue, since really nothing more was happening, at least not in "kind", but only in "number". so, let me know if it happens to you ;-) i suspect i ran into yet another mozilla limit.
side note: saw that the server event log had twice-daily issues with a particular feed using an old approach that someone was still accessing (craig, i think - ?), so i just made it server.transfer to the new one. someone is going to start getting new items after - months ? years ? ;-)
fixed the menu behavior, and made a few other tweaks here & there so at least the basics of the site are operable in ff. lots of broken stuff on individual pages though, still to do.
briefly looked at what was in my site map / menu data. really, by now the purpose has changed for all of this. it was originally put together to help me locate various odds & ends related to my presence on the web. but now that presence has expanded quite a bit in different ways, and i think it's time to rethink things. i'll fix broken links, etc. at that point, if needed.
not today, though.
not sure what to do about those .xsl's using ms extensions. once i get that thought out i'll finish the rest of the transform stuff.
so, like, i re-do all of this code & stuff & finally, finally get shit working to the point where i can look at specific usage issues, and i find two three issues:
- a number of my .xsl's use msxml extensions
- ie can allow cross-domain access, but ff cannot
- handling of xml data islands in ff
at this point it looks like my cross-browser transform.htc is working just fine. even managed to improve it substantially, although some - interesting - quirks remain. added tracing, error handling; revamped the logic; refactored the implementation.
one thing i've never worked out is how to tell what is calling an event handler when multiple objects share the same handler. i created some work-around for this. i don't really expect "window.event" or "this" to give me what i need, but i still need to check. i'm sure i looked into this multiple times over the years, but nothing came up.
it's the first of the two three items that is the big question mark. dealing with those extensions, with exslt or some such, will be a problem. basically, i use some string & date handling, but exslt support among browsers seems scant to non-existent. do i need to fork my .xsl's ? seems to be the case.
the cross-domain access stuff can be handled with server-side xml proxies. think page scraping with no interpretation needed. what the hell, not too difficult, but two-stepping this shit through my own server seems silly.
still working on that last item. ff is doing some strange things to the dom structure there.
i'm really thinking i should revert to server-side handling of these transforms, obsoleting all the work i've just completed. and i've got some code i did a couple years ago for this. but that wasn't the purpose behind this exercise.
there was a purpose, wasn't there ?
anyway, as this particular behavior is the coronerstone (heh) of my website, i think i'll stop here and ponder. there's no point in doing the rest of these if this one won't work out the way i want.
well, the mozilla behavior wrapper for htc's is one thing, getting the cross-browser implementation right is quite another.
this next htc that i'm working on is my "transform" behavior. it's purpose is to allow client-side declarative xml/xsl tranforms:
<style>
#divTransform {
behavior: url(transform.htc);
-moz-binding: url(bindings.xml#transform-moz.htc);
}
</style>
...
<div
id="divTransform"
hrefXML="main.opml"
hrefXSL="main_opml.xsl"
asynch="true"
load="true"
>
loading csweb main opml...
</div>
but that says nothing about how completely different such processing is done in ie v. ff. rather than use a single htc and effectively branch everything anyway using browser detection, i may as well use the behavior binding css differences to do that for me, and encapsulate the separate implementations in separate files. makes much more sense. [but then i didn't do it this way in the end anyway ;-) there turned out to be far more in common than different, so i got my wish in the next paragraph.]
i wish i could keep the interface details in common, though. and really, the logic is the same as well. what i really need is a generic xml processing wrapper. *can of worms, can of worms*
surely that's been done. well, there's the e4x stuff, but not for ie. or json, but that's not the data i'm handling. too bad i'm all done but for the debugging.
[insert hours of elapsed time here]
whew. well, that was interesting. had to get into a whole lot of other materials on the web for this one. pretty cool. that's why i do this shit. still don't have the mozilla version up & running yet, and there are a lot of css changes needed on my site.
primary resources:
i'll continue tomorrow; time to veg now.
things i had to do to make mozilla behavior binding work with my old htc's:
- added the -moz-binding properties to my css (as per the article)
- move the implementation script into the interface xml (as per the article)
- add commented cdata wrapper to the script (as per the article)
- removed the urlscan isapi filter from iis. this seemed to have been preventing the ability of xmlhttprequest to access an htc file.
- add xmlns:public="[bullshit]" to the root element. the absence of a namespace declaration was causing the xml not to parse.
- add get/put functions & references for properties previously only exposed as fields. the xbl wrapper doesn't handle fields.
- work around "sourceindex" usage. this is an ie-only thing in my earlier implementation, used as an index in document.all().
- work around #text nodes. this is a mozilla thing not seen in an ie-only implementation.
- work around a dynamically attached handler. onpropertychange seemed not to work.
note that there only needs to be one moz-behaviors.xml file and that this can be referenced by absolute or relative paths in the bindings.xml file(s). the latter, however, must exist in the same location as the htc's that it's used to reference, since the wrapper parses the css -moz-binding url(...) value to come up with the location of the htc.
while i was at all this, i noticed that community server was modifying the contents of script tags used in the blog news setting. it was escaping quotes - ! yuk. so then i moved that script into a separate file, and sure enough ran into racing conditions. *sigh*
got all that figured out. pain in the ass, let me tell ya, when all these different - and different kinds of - issues are happpening all at once.
another thing i noticed early on was that some sort of severe error was causing the elements referenced by the bindings not to render at all. i don't have this pinned down quite yet as to exactly what sort of breakage does this. maybe it was the urlscan return...
anywho, that was htc #1. got a bunch more to go, and then, even worse, a shitload of javascript to remedy. one lesson learned: debugging usage with an app only hosted remotely just intensified the pain. silly me.
why go through all this ? i dunno; ... "why not" ? not good enough, given all the new tech. and then there's the server side stuff that can be done. bottom line is that this has been a bit of a thorn for years, and i just wanted to see if it could be done, and how painful it would be if it could.
as for the ie / ff debate, well, everyone's shit is broke, in one way or another. and there's good points on both sides too. the discriminator is market share. if i'm going to code for only one thing, better make it the biggest thing out there. what do we really gain from having more than one browser or other technology ? don't we share the same roads, the same internet ?
and on that final note, i heard someone saying their employer doesn't want them using soap - ! (beware the intentionally ambiguous here)
gonads.
more:
From: service@laptopgiving.org
Sent: 2008.01.24 02:30:26 Eastern Standard Time
Subj: Your XO Laptop
Dear Donor,
We wrote you several days ago to let you know that your donation is in our shipping queue for the shipment of your XO laptop.
We are awaiting the arrival of new inventory so that we may ship your laptop to you. We will send you another update in the next few days when we have specific shipping information.
We appreciate your generosity and patience.
Sincerely,
OLPC Donor Services
kind of what i thought. not a problem. shouldn't the kids come first anyway ?
-
attribution issus, at least
-
oh - my - god - what we've all been waiting for - and so much other good stuff on that site ! amazing.
... my stylesheets to account for ie7. ***
when i first did those i often didn't use units when specifying margins and padding, and some other positioning settings. as ie7 tried to be more standards compliant, it broke those shortcuts. and i discovered & fixed a few other problems as well.
now, this doesn't mean the site looks any better; it just means it's back to it's original bone-headed intent.
there's still stuff on the menu that needs removing / changing / adding, and perhaps some other updates (like maybe automatically pulling from the wayback machine for old broken links).
*** no, i'm not doing ff ! - unless ff can do dhtml behaviors - dang - wait a minute ... - someone test this & let me know - so why hasn't this been added to the base code ? or has it by now ? no, probably not yet - see W3C: Behavioral Extensions to CSS (2007.10.19 draft).
and i would still have to work out my cross-browser use of xml/xslt, along with some mods to the htc's, among other things. and then there's the odds & end stand-alone javascript. eh, maybe i'll get bored soon.
highly recommended though: dean.edwards.name
ok, i did the mozilla behavior binding thing; just to show how much i care, i don't have ff installed here, so i didn't test it ;-) at least i didn't break the ie stuff.
still a lot to do with community server (add-ins, mainly) and my own site. eventually when i get all these basics done, then i'll return & implement "ie7" & finally redesign the appearance / layout of all this crap. and then start all over ...
ain't website ownership wunnerful ?
so it took them a couple weeks / months to get their shit together, so what ? they're being responsive now, anyway:
From: service@laptopgiving.org
Sent: 2008.01.21 05:58:54 Eastern Standard Time
Subj: Your Give One Get One Donation
Dear Donor,
We are contacting you in regards to your Give One Get One donation and the shipment of your laptop. Your donation is in the queue for laptop shipment.
Please expect to receive another update from us by Wednesday, 1/23, with information on when you can expect to receive your laptop.
We appreciate your generosity and patience.
Sincerely,
OLPC Donor Services
the various snafus that they have been having sure caused a lot of upset. in retrospect, it's a "well, what did you expect?" kind of thing. unfortunately, it still adds to that program's bad pr, despite that a lot of it can be chalked up to the usual "ugly american"-ism.
there are people out there who have called lawyers, state attorney generals (or is that "attorneys general" ?), have spent hours on the phone for weeks, bombarded every inbox they could find at the partner organizations, filled forums... all this over a $200 missing slightly late item. good god - i can blow more than that in two weeks at the local bar. and i guess we've forgotten the days when all mail order items took "6-10 weeks" to be delivered. damned instant gratification world.
which kind of makes one ponder the reality that motivates the creation of this and other programs. i've said it before - there's now enough aggregate wealth on this planet to eliminate poverty - and so many associated conditions. and for most potential contributors, this would hardly make a noticeable dent in their lifestyles. (yet it seems most of what support does exist comes from the global middle class that is rapidly being wiped out. makes one wonder if it ever really existed - it hasn't, in historical terms. wups, another post.)
well, fine, but then there's ayn rand's warnings, and that's something to be considered as well. and our recent experience in iraq. you can't simply "give" economic, political, personal security. educate, you say ? thus, the olpc program.
cliffs notes version:
in both cases, you're immortal !
suffering or savoring, one still retains one's memories - one's being - forever.
now, welcome to the the atheist's world - when you're gone, you're gone.
hell of a thought, eh ? and that applies to time frames from instantaneous to a lifetime. horrible accidental death ? no problem - you'll never have a chance to "remember" anything. but, extending the subjective time concept, that applies to all experience. of what import "suffering" ? death early or late is still death. the imaginations of "survivors" are of no import. at all. one cannot experience non-existence.
so, what period of "suffering" is, uh - "acceptable" - ? in the end, with respect to the human experience of time, all periods are infinitesimal.
looking for a rationale for 'survival' here ...
More Posts
Next page »