http://news.msu.edu/story/5606/

Here are some excerpts:

"In a paper recently published in the journal Animal Behaviour, Smith, a student in MSU’s Department of Zoology, shows that while spotted hyenas know the value of living together in large, cooperative societies, they also realize that venturing on their own now and then to hunt for food is often the key to their survival."

...

“Although spotted hyenas are 20 percent more likely to capture prey with one or more members of their social group, cooperative hunting results in multiple new competitors showing up because former allies quickly turn into noisy competitors once the kill is made,” she said. “So it’s the individual, especially if he or she is low in the hierarchy, that suffers a cost for having group members at that prey.”

I think that the relationship between the individual and the collective happens in open source in general at the personal level and in organizations like Sakai where institutions are stakeholders, it also happens at the institutional level.

http://mfeldstein.com/connecting-blackboard-to-sakai-and-moodle/

It followed up this excellent blog post by Michael Korcuska:

http://sakaiblog.korcuska.net/2008/07/16/blackboard-sakai-connector/

I just had to comment in Michael F's blog - could not resist... Here is my comment...

The Sakai Community and the Sakai Foundation are not one and the same. I sort-of like your suggestion that the Foundation not invest any *Foundation* resources in helping make something "non-open" happen. However, members of the community can do whatever they decide to do.

However I think that it would be wrong for the Foundation to make such a strong statement completely closing the door on any interaction because of the patent.

Back when I was the Sakai Executive Director, I felt that it was very important to engage potential stakeholders in the Sakai product and community regardless of their use of patents or the openness of their source. Because I felt that open source should be open - open source should be an example of how to win without being protectionist.

Under this principle that I gave to myself - I engaged in many discussions with a number of companies who are notorius for having and using patents and for keeping their source closed. And I even talked to them under NDA terms to help align their strategies w.r.t. Sakai internally before making external commitment statements.

These "bad" companies include: Oracle, Apple, Microsoft, IBM, and others. Also some of the academic members of Sakai hold nasty little patents - I think one of these academic patents is in the top 10 villains on the EFF patent busters effort - but we let Sakai resources benefit Universities that hold and exploit patents that cover our space.

My perspective was that it was not my place to just "good companies" and "bad companies". Some members of the Sakai Foundation Board and Sakai Community were often concerned when I initially engaged each of these companies as the ED. But overall after a while people relaxed and realized that nothing bad happened to us by talking to Oracle - that we effectively were protected because we were "open" and as long as Sakai stayed true to its own values - consorting with Oracle or Microsoft did not change our values.

And actually working with Oracle has had wonderful benefits - both to Sakai and to the market in general - your leadership in the IMS Learner Information Service - is awesome - Oracle's investment in a public good is much appreciated - at least by me.

I never look at corporate decisions as "good" or "evil" - they are either "smart" or "dumb". I think that Oracle's decision to engage in Sakai and IMS is "smart". I think that BlackBoard's engagement of open source is "smart". I think that BlackBoard's work in IMS Tools Interoperability is "smart". I think that the way BlackBoard granted patent immunity to Open Source is "smart". I think that the way BlackBoard pursued the D2L patent is "dumb". Not "evil" - not "good" - just "dumb".

I think that the market impact of the "dumb" BlackBoard decision has already caused negative consequences to BlackBoard - I think some of your earlier posts about dwindling market share are best explained as the results of management mistakes made by BlackBoard. I actually trust the market to punish "dumb" things and reward "smart" things - so my opinion really does not matter.

If I am asked - I always tell companies what I think the "smart" choice should be. I always preface my advice with the following variant of Sarbanes-Oxley: "Thanks for asking for my opinion on this matter, just so you know - I am just a humble academic with no real business experience, but if I were facing this decision, I would ...."

When you upgrade your original iPhone to the 2.0 software - you can do geotagging of photos.

When I pull the photos into iPhoto - and do CMD-I I see GPS coordinates. These are as right as they can be using triangulation/Wifi tricks - but they are at least *close*.

It seems that FLickr does not see the meta data yet - flick does not even know that the photo came from an iPhone.

But I am sure this will all work out.

I wish I knew a site that I could upload a photo and have it dump all the metadata.

Given that I don't have 3G in Lansing where I live and that Geotagging was my most important feature - it means that I don't have to rush right out to get the new iPhone - I will still get one eventually - I will just let the craziness die down a bit.

http://www.insidehighered.com/news/2008/07/15/sakai

I added a comment to the article:

When dealing with a company - we should always assume that their purpose is to increase profit. Increasingly, companies realize that by creating *truly open* ecologies around their product - they make *more* money rather then less money. When customers perceive the market as "fair" generally overall investment increases across the board. When there is a real or perceived battle between open source and proprietary companies, many organizations with money "stand pat" and invest in neither until things settle down.

Part of making a truly open ecology is standards - I work with IMS (www.imsglobal.org) and we have been developing standards like IMS Learning Tools Interoperability and others that touch on these areas. Blackboard is participating in these efforts and we hope that much of the aspects of the connector will ultimately be covered by formal, published, and interoperable standards.

But it is a delicate balancing act - products and standards move at different paces - if we wait for a perfect standard - products will be held off forever. If we never build a product - we never reveal the fine technical details needed in the standard.

When I look at all of this, the balance tips towards being engaged in the effort and trying to influence the direction to ultimately improve the experience of teachers and learners regardless of what enterprise CMS system their school or campus happens to have installed.

I think that we as a community (or at least a few of us) have a choice. We can either be part of this effort and affect it so as to produce the best possible outcome for everyone - or we can ignore it and hope it goes away.

If we choose to ignore it - BlackBoard will not stop - Sakai is open source with a commercial friendly license - Sakai's commercial partners already take Sakai modify Sakai and sell product / service around it. How is BlackBoard doing the same thing somehow different? If company *A* sells services and software and promotes Sakai use that is great and helps build the Sakai community - but if company *B* sells services and software and promotes Sakai use - that is bad and clearly straight from the Devil? At least we should be consistent.

Feel free as an individual or even a school to like or hate BlackBoard all you like - and perhaps part of the reason some folks like Sakai is because they hate BlackBoard - whatever gets you working - I am happy to see that. But please don't suggest that by being part of Sakai as an adopting institution or contributing developer - that somehow we all signed the "anti-BlackBoard" pact.

Sakai is about "freedom and choice" - Sakai is about win-win not win-lose - Sakai is about making teaching and learning better. Sakai is positive energy - not negative energy.

Think about the Apache web server - The Apache Foundation and the Apache Community does not think of WebSphere as the Devil. As a matter of fact revenues from WebSphere fund developers to work on the free Apache that we all know, love, and use. WebSphere and Apache HTTPD are not enemies - they are *alternatives*. Having commercial and open source products that are compatible and closely aligned - increases our freedom.

Open Source is there to make sure that we keep our freedom and alternatives - when an Open Source community decides that increasing market share at all costs is a high priority - then it has become a company that happens to release its source code - instead of an open source project. When this happens, the entire value system changes and frankly we then lose that magical quality that is open source.

I think that this is a good opportunity for the Sakai community to reflect a bit and perhaps think about our core values and the extent to which we all really understand what "open" means.

This was an AWSOME summit. I particularly recommend the John King Keynote speech about what makes learning happen - and the panel discussion of all the attorneys fighting about Fair Use. Of course I am on the Functionality Mashup panel - I warn you that my panel is not nearly as entertaining as the Fair Use panel.

http://inst-tech.engin.umich.edu/media/?sk=imsum08

The web site also demonstrates a pretty impressive lecture recording capability provided by the University of Michigan School of Engineering.

Hi All,

I am a developer at UNISA. We have to decide what will be the best framework to use in future. We want to become more involved/contribute in Sakai.

We are using struts currently but must decide now if we are going to use RSF, VM, continue using struts or use something else. We don't want to build in unnecessary complication in our codes as we battle to get developers with the right skills and we had 3 resignation in the last 2 months. Questions that game up during our discussion were:
* Will struts be accepted by the Sakai Community?
* What is the general feeling about RSF in the Sakai Community? I found that some hate it and others love it, but I guess you get that with any programming language.
* Can any framework be used in Sakai as long as the tool work?

Do you have any suggestions to help us with our decision please?

-- Sonette

This is a tough question - there are many opinions - this is my opinion:

- Sakai supports a lot of frameworks - so you can choose - as you say - choice is frustrating and wonderful at the same time.

- If you are building something for UNISA only - I would go ahead and use Struts - it will be around for a long time and there is no reason to expect Struts support to become problematic in Sakai

- If you want to build a new tool with wide distribution of a tool across the Sakai community - RSF is the right choice of today - most new work intended for broad distribution I know of is being done in RSF.  I would advise against using either JSF or the Jetspeed-inspired Velocity pattern.  Neither of these comfortably supports the kinds of web 2.0 kind of stuff that will become increasingly important. In RSF you can gently move between UI stuff and Web 2 things like RSS feeds without hacking things.

- The sdata / widget approach is indeed the promise of the future - but it does not yet work with any shipping version of Sakai and will see its first production use in Cambridge in a few weeks.   I suggest letting it settle down in production for a while and see what comes out in Sakai 2.6 to make sure that the future direction for this technology is really worked out.   A key to this new approach is that tools end up with a complete redesign - assuming Ajax means that the UI for a complex and powerful tool looks much simpler - so tools end up being built (pretty quickly) from a fresh ground-up perspective.  In addition RSF tools will work in the new world in a backwards compatibility mode for a long time.

Of course the SOLO work is all GWT - which looks very awesome - other projects such as OpenSyllabus are using GWT - for now this is interesting and we will have to see how GWT in Sakai shakes out.

So, if you factor all the risks/probabilities - the safest path forward for now is probably Struts for internal UNISA stuff and RSF if you want to build a tool for the rest of us.  As you build new capabilities - make sure that you use a service oriented approach and separate your model from your controller/view -because you might end up making a widget to view the data in addition to the RSF tool.  If your APIs are clean - making the widget (or GWT version) will be much simpler than if you just mash the presentation and model code together.

Take a look Aaron Zeckowski's GenericDAO code for good API patterns:

https://source.sakaiproject.org/contrib/programmerscafe/genericdao/trunk/

Good APIs lead to good REST interfaces which lead to cool support in SOLO and easy to build widgets.

/Chuck

Luckily my new conversion code is a *much* better sample to work from - because it is simple. Some documentation should be written.

So it is now off to Tony for testing. More detail below.

Now I am off to go get my motorcycle gear from www.ridersdiscount.com. So for the rest of the day - call the cell.

Grab the following branches:

https://source.sakaiproject.org/svn/db/branches/SAK-13584/
https://source.sakaiproject.org/svn/mailarchive/branches/SAK-13584/
https://source.sakaiproject.org/svn/util/branches/SAK-13584/

Compile and deploy

Run the conversion

cd mailarchive

Edit upgradeschema-mysql.config to get the database connection right.

Run the script:

sh mailarchive-runconversion.sh \
-j "/Users/csev/dev/sakai-trunk/apache-tomcat-5.5.23/common/lib/mysql-connector-java-5.1.6-bin.jar" \
-p "/Users/csev/dev/sakai-trunk/apache-tomcat-5.5.23/sakai/sakai.properties" \
upgradeschema-mysql.config

Check to see if the BODY, SUBJECT, and HTMLBODY columns look reasonable. The conversion can be stopped and started. If you want to undo the conversion simply execute these commands:

ALTER TABLE MAILARCHIVE_MESSAGE DROP COLUMN SUBJECT;
ALTER TABLE MAILARCHIVE_MESSAGE DROP COLUMN BODY;
ALTER TABLE MAILARCHIVE_MESSAGE DROP COLUMN HTMLBODY;

--Chuck

Test Scenario for this interim version - RUN this test and send me catalina.out

Here are the needed clicks - keep track of which ones are dog slow and which ones are fast. I expect that the non-search queries will be quite fast. And even the search queries should be tolerable.

Go to the mail tool in a site with lots of messages - do not enter a search value

Press next page 2 times
Press back page
Press last page
Press back page twice
Press first page
Enter a message
Press next message twice
Press back message once

Switch to Sort by Subject
Switch to Ascending and descending
Press back page
Press last page
Press back page twice
Press first page

Now put in a search string that is common and repeat the above steps.

Now put in a rare search string and repeat the above steps.

Send me back the catalina.out - thanks muchly

Here are the relevant JIRAs:

http://jira.sakaiproject.org/jira/browse/SAK-13584 (2.6 improvements)
http://jira.sakaiproject.org/jira/browse/SAK-11544 (2.5 improvements)

I will check it into a set of branches soon for some more extensive testing across more databases.

Here is a summary of the changes:

- Fully normalized the MAILARCHIVE_MESSAGE table - all fields are in columns now. The XML must stay for a while (more below) but it is not used for any search or selection.

- Added Aaron's GenericDAO concepts to org.sakaiproject.javax - with some improvements. Order and Restrictions are unchanged. Search has become Query. I added a searchString property to Query and added a few setters which were missing.

- Changed the BaseDbDouble ORM code to support the new genericDAO pattern when it sees a fully normalized table. When it sees a search, it uses a where clause instead of scanning all the data in Java. Also it understand the notion of search fields as well as order by fields. And from the 2.5 modification, paging is implicit throughout as well. Now the BaseDoubleDb can get either a count of messages or a list of messages using Search, Order, and Paging with a single DB query that returns *exactly* the right row set and nothing more.

- Changed the MailArchiveTool to use as little session state as possible. I moved some information into REST-based URLs. Also any heavywieght information is put into Context, never in session. This leaves the MailArchiveTool with a small session state with a few strings and integers - and everything left in Session should be trivially serializable.

This restores all functionality of the MailArchive tool regardless of the size of the message corpus. Each screen display is exactly one SQL statement to pull back *exactly* the required data searched and sorted in the database.

This makes it *REALLY* easy to come up with a really efficient webservice or sdata feed for Mail Archive - since you can search, order, and scope data above the API - you can produce *exactly* the JSON you need to implement a sweet dynamically scroll view of MailArchive where as you scroll off the bottom, the next 100 or so messages come from the server.

This also allows very efficient retrieval of messages for something like the SOLO offline Sakai client that Psybergate has produced with UNISA and NWU or other Google Gears views of a site's MailArchive Corpus. When SOLO meets SDATA at some future point in time - it might be a shot "heard round the world".

In general, I am pretty excited about the possibility of moving a legacy tool from being XML-based- to be very efficient and REST friendly. It was not that hard - once I fixed the DB layer to understand Query - I was mostly removing code from the Controller/View code (MailboxAction.java is much smaller now).

I really wanted to get the session to nearly zero and have Restful URLs for everything. But interestingly because the portlet model has this notion of Action and View being separated (often by a redirect on post), it makes it harder to put all of your state into the URL :(. So the compromise is a bit of session (as little as possible and all serializable) use REST urls as much as possible to let the back button work a little better - at least when you go back and click on a different button in a list view - you get the right message :). I need to do more study on this. JSR-168 has some features that make the back button more friendly than the old Jetspeed pattern.

The problem with the back button is really traced more to the Jetspeed 1.0 portlet pattern - it is not something inherent in using Velocity. And interestingly, this is another moment in time where my respect for the thought that went into JSR-168 grows.

I will begin checking this stuff in soon. I need to take a brain break and think about something else for a day or so and then review it before I make all my branches so folks can take a look.

- Testing across all databases

- Think about a caching layer inside of MailArchiveService - it would only be worth it if there was searching happening on a very very large corpus of mail. But I don't want to optimize this without some tests on a large Corpus. (hint hint Tony)

- Implement the Restrictions from GenericDAO in BaseDbDouble - not just search - make sure to support both Restrictions and Support - or perhaps decide to do that later since MailArchive won't exercise it. Maybe just a warn for now.

- Make sure to refuse to search, restrict, or order on fields not supported - do this in DbMailArchiveService

- Work with Aaron to come up with a single world-view of GenericDAO - I hope he will like my improvements. I wish I could have had a beer - but we *just* missed each other in Cambridge this week.

FUTURE WORK:

I may look into doing this same exercise for the old Chat1 code - it should drop in pretty easily - Chat1 is even simpler than MailArchive. If folks are still using Chat1, I might be motivated to do it for 2.6. Let me know if you are interested in speeding up Chat1 and normalizing its data.

This paves the way for a whole new implementation of DbMailArchiveService - completely removing any dependance on the the DB ORM pattern and re-implement in either Generic DAO *or* perhaps Cayenne. When this is done, the XML column can be dropped completely. There is a little sticky wicket to think through - whether to drop the notion of accept() in Filters. I don't plan to do this until after 2.6 is done - just something for me to think about for a while.

This was our second European conference - I think that it worked well - we met many new faces - this is always important for open source. I wish we could have gone sometime other than the middle of summer - there were too many tourists in Paris :).

Probably the most exciting part of this conference was the participation of teachers. Thanks to Josh Baron of Marist - we had a great contest for the best use of Sakai with two wonderful winners who gave wonderful presentations. The coolest thing was the fact that half the room was filled with developers and tech support folks.

Usually we are told what is wrong or what needs fixing or what is hard to use about this software that we work so hard to make better. It was nice to hear from someone who *loved* using Sakai and felt that Sakai enabled them to teach better. I know that I could not teach the way I want to teach on any other learning management system - period. So while we are continuously bombarded about how we can improve (aka criticisim) - we need to remember that what we have here is pretty damn functional as we stand.

The other amazing thing was the amount of innovation *around* Sakai - the SOLO offline system using Google GWT and Gears was amazing, the IMS ePortfolio export from Edia was amazing, seeing folks working on the Open Syllabus in GWT was neat as well. Of course the MyCamTools stuff just gets better and better every time I see it.

I had spent some time working on McGraw-Hill's Katana before Paris and helped write their install documentation. I like the MHE approach because it gives teachers control over the organization and arrangement of the content and allows them to edit the content other than the learning modules. The large and complex learning modules are served from the MHE servers. The software is free, the content is free for teachers t explore - and only the students pay (like a book) when the teacher decides to use the content. Very cool. The Katana content is not part of a book - it is useful materials that can be used with any book - McGraw-Hill or otherwise. I want to get MHE to use IMS LTI as well so we can quickly get Katana Content into Blackboard and Moodle and other places as well.

The whole Michigan team had some good talks with Michael Feldstein and John Lewis about doing some early work with the IMS Learner Information Services spec. I would really like to see that happen.

The food was great - I went to the Eiffel Tower and Notre-Dame and not much else tourist wise.

I am really looking forward to the regional conferences for Sakai now that we have moved to an annual conference. I have a feeling that the Virginia Tech teaching with Sakai meeting will be awesome.

Here are my talks:

Teaching in the Open

http://www-personal.umich.edu/~csev/talks/2008/2008-06-30-teaching-open.pdf

Functionality Mashup - IMS Learning Tools Interoperability

http://www-personal.umich.edu/~csev/talks/2008/2008-07-03-lti-sakai.mp3
http://www-personal.umich.edu/~csev/talks/2008/2008-07-03-lti-sakai.ppt

Then Jordi and I spent about an hour designing the Moodle Module and Filter for the Simple LTI consumer tool. We talked about the structures and what additional features to add if we got done early. The basic outline was to work on the Launcher, the admin configuration of final configuration variables, virtual tools, a two-layer identity data sandbox mechanism, and a set of admin tracking, monitoring, white-list/black-list features under the control of the administrator.

Then Marc, Jordi, and I went to the beach on bikes. It was very nice and warm and we took a short swim. The cardinality of the set of female beach clothing configurations was one larger than on any other beach I had visited before - so that was an interesting experience.

When we got back we had Horchata and ice cream and talked about Texas Hold-em poker and how America might change as gas prices continue to increase.

P.S. Spain has already lowered their national speed limit to conserve fuel - making all unhappy - which might come to the US sooner than we think.

After a long day of talking eating, drinking, talking and drawing architecture diagrams on napkins - we were going back to my hotel. Earlier I had told the group all about one of my favourite books - "The Innovators Dilemma".

http://www.claytonchristensen.com/publications/

On the drive to the hotel one of my new pals told me of one of his favourite books titled "The Starfish and the Spider - The Unstoppable Power of Leaderless Organizations".

http://www.starfishandspider.com/

Here is the short synopsis - the Spider is a hierarchical organization where each piece does its precise part in well-organized concert with the other parts of the spider. You can kill a Spider by putting a tiny pin through the Spider at that one place where it is all controlled.

The Starfish by contrast is a collective of pretty independent units. While none of the bits can stand alone - you can cut off a whole leg of a starfish and it will grow back - or if you chop a starfish in half you will end up with two starfishes. So while a starfish needs some minimal sized chunk to survive - it is pretty robust when it is injured and no single injury can kill the Starfish.

The book talks about how the Spanish invaders quickly conquered the Aztecs and Incas with 100 soldiers by figuring out the leader and killing the leadership (Spider killed by a tiny pin). However as they moved north, the encountered the Apaches. The Apaches were an open source project derived form the original NCSA httpd server. (Sorry - I slipped into the wrong story for a moment there).

The Apaches were a decentralized free society that operated in a collective manner but where participation in collective action was voluntary. So there was no real leader of the Apaches. When the invaders found someone who *looked like a leader* and killed that person - it was just the old medicine man - who was the spiritual leader- and while the tribe certainly must have missed the medicine man and hearing long stories about the ways of the ancient ones around the campfire - ultimately the loss of the medicine man did not stop the Apaches from organizing to wage war and chopping the Spaniards into small pieces.

After a while the Spaniards figured out that sneaking 100 soldiers into the middle of a big gathering of Apaches and killing one medicine man - just resulted in a lot of Spaniard pate'.

So how did the Apaches finally lose? According to the book, the United States much later turned the Starfish *into* a Spider. They took only a few of the Apaches - told them they were "special" - and gave these new special Apaches some cows. The ownership of a cow proved to be pretty cool - milk, baby cows for Veal Parmesan, Ruth Chris Filet Mignons cooked at 1800 degrees soaked in butter - all that. Feeding the whole tribe Ruth Chris steaks got one a lot of street cred that could be used later when decisions needed to be made.

The cows caused structure to appear in the society - and folks started keeping track of who was up and who was down - the Apaches were no longer equals in a loose, flexible, and dynamic collective - there was a class structure - and who you were and where you fit in the cow owner society started to matter and structure formed.

While the Starfish is generally pretty resilient in the face of obvious and seemingly damaging frontal attacks, it is fascinating how collective adaptive organizations (Starfish) can slowly be transformed into hierarchical static organizations (Spiders) by coming in the back door - intending to "help" and treating some members of the collective as "special".

In looking at things there were several instances of "too many queries" - not just from 2.5 - but for a few features that were added to portal between 2.3 and 2.5.

So I pored over the code for the last three days and figured out what kind of optimization which had already been done - and figure out where bits were leaking through the prior optimization.

I talked to Aaron and Ian - and came up with two solutions - one using memcache for the properties and another using thread local.

I think that this will be important for Sakai 2.5 sites - My guess is that in the summer many are not noticing the additional query load on the main portal displays. Without these patches things will likely slow down a bit and/or consumer more resources.

I initially made a property to control which tables the properties get cached in memory - my guess is that particularly for 64-bit JVM's this should be

DbFlatPropertiesCache=:all:

But at a minimum this is needed:

DbFlatPropertiesCache=:SAKAI_SITE_PROPERTY:

After some testing and experience we should figure out which of these two should be the default. I think that the methodology (suggested by Ian) is to look at query patterns and see if you are seeing too many hits on tables like:

SAKAI_SITE_PAGE_PROPERTY, SAKAI_SITE_TOOL_PROPERTY, SAKAI_SITE_GROUP_PROPERTY, ...

Then simply add them to the list in preferences - and see if things get better.

This is a nice, clean, short-lived memcache - and it is automated perfectly when properties are changed on the same server (i.e. when an instructor makes a change and presses refresh - the display will be perfect - instantly reflecting the changes).

The Thread Local code is obvious and must be done. It simply makes sure that the portal only gets the list of visitable sites once from the database.

Both of these mods are really simple and clean and should be trivial to review.

I currently have some print statements that can be uncommented if folks want to watch the new caches in action.

Once some testing happens - I will remove these before sending it to trunk.

Now this is done, I can start working on my talk for tomorrow about functionality mashup.

Here is my message to the dev list about it.

https://source.sakaiproject.org/svn/db/branches/SAK-13886

https://source.sakaiproject.org/svn/portal/branches/SAK-13886

This is all described here:

http://bugs.sakaiproject.org/jira/browse/SAK-13886

Since this is a cache thing and thread local thing - I am happy for
folks to look it over before I move it to trunk.

Once this is done I expect to put it into 2-5-x - I would guess that
folks will want this performance fix to get the portal views less
costly in terms of the number of queries needed to produce the main
page.

This one is pretty simple - add a battery-backed up light or LED to garage door openers so that when power fails, the light comes on and makes it safe to go through the garage. You just need to put electronic logic for the charging and lighting and a battery.

You could do these separately - but it would be really nice to just have this a feature of all garage door openers for safety.

The batteries would need to be replaceable - it would be nice to use low power LEDs which have a good light to power ration - and then you could probably do this with 4-6 rechargable AA-cells and get a few hours of light.

Picture:

Update: This patent has already been challenged based on prior art. Aaron Z showed me this page:

http://www.lonestardoor.com/wd_doormaster.html

With this quote:

It even features emergency battery-powered operation!

* U.S. Patent No. 413,867

Innovative technology that provides maximum safety, convenience and security for your home and family.

And Aaron actually had such an opener. So that might suggest that my blog-patent is not worth much - but with Byzantine Patent law - it might still work out nicely for me - even though there is a long-standing product in the market - and a patent - it is OK. Part of the patent process is disclosing any prior art you know of - so this is my official disclosure.

The idea is pretty simple and shown in this picture:

The idea is to make a simple cord - on one end is a female MagSafe adaptor and on the other end is a male MagSafe adaptor.

It allows old power supplies to be used with new computers - it keeps folks from buying too many double power supplies - such as for home and work. One power supply can be used for many computers.

So more surgery seems necessary. I did some more digging and came up with this discussion:

http://discussions.apple.com/thread.jspa?threadID=1183455

This adds some good hacking to the reset pattern - you go into a weird directory and delete a weirdly named file - this sounds like the kind of stuff that will work.

I really don't want to jailbreak my phone for the sole purpose of working around a bug that Apple could fix with one hand tied behind its back!

The trick is to delete a file that configures the "next photo number". Interestingly in the file that I deleted and in the file mentioned in the above it has moved beyond taking 1023 or 1024 pictures. Hmm - something crapping out when it is near a power of two.

My hypothesis is that this problem is probably a combination of iPhoto and iPhone and when we delete the file - we avoid the problem for the next 1024 pictures... Hmmm.

The cool thing about this is that once you perform this - you can once again go into iPhoto - import all, and then delete all - and your iPhone camera is not bricked! Also you can manually delete all the photos on the iPhone and the camera is not bricked.

So it seems as though you just need to backup your iPhone, Restore it to factory settings, remove this file than Restore the iPhone from backup and you have another 1024 worry-free pictures! Only time will tell. In a funny irony, one of the blog posts was titled "My iPhone ran out of film!" - in a way - this is true - because of the bug, some iPhones only have 1024 pictures in them when they come from the factory - so it did run out of film. OK - perhaps that was only funny to me.

The nice thing is that now that I have a workaround for the bug, I don't need to buy a 3G phone quite so soon - a phone without a camera - really makes me unhappy.

At some point I got so mad that I went into conspiracy mode and suspected Apple of introducing this bug - just to get me to buy a 3G phone - because I never saw it until the 1.1.4 update - but if it is just a 1024 issue - the more rational explanation is that it just took me that long to get to 1024 pictures.

It would be good if folks who find their iPhone camera messed up to look at the contents of the file and see if the 1024 (or 1023) pattern holds.

My instructions are below.]]> 501 cd ~/Library/ 502 ls 503 find . -name 'e968*' 504 cd Application\ Support/MobileSync/Backup/ 505 ls 506 cd 41aedf3aa971f24ca76f20053f63f164c78f929b/ 507 ls 508 vi f1b43d3b3ecf259a3626c13a8b0cebd8ba513117.mdbackup <plist version="1.0"> <dict> <key>LastFileGroupNumber-100</key> <integer>1023</integer> <key>LastFileGroupNumber-101</key> <integer>92</integer> </dict> </plist> 511 rm f1b43d3b3ecf259a3626c13a8b0cebd8ba513117.mdbackup Restored iPhone from iTunes Restored from Backup when prompted Look at the file again: <plist version="1.0"> <dict> <key>LastFileGroupNumber-100</key> <integer>5</integer> </dict> </plist> ]]>