March 2004 - Posts

The InfoPath team is blogging, say no more!

Location: http://blogs.msdn.com/infopath/

RSS feed: http://blogs.msdn.com/infopath/Rss.aspx

 

Posted by erobillard | 1 comment(s)
Filed under: ,

After seeing and article about PocketVault on the Wired site, my first question was “what prevents a clerk from swiping my plastic through their own Pocket Vault?” I submitted the question through their web site and received a great response within a few days:

Dear Eli:

Nothing.  But the act of swiping your card or anyone else’s card through a different person’s Pocket Vault will not result in that card being loaded onto that Pocket Vault.  Here is how the loading works, in summary:

Credit and debit cards can only be loaded to a person's Pocket Vault while the Pocket Vault is docked to a PC or Mac and the legitimate owner of the Pocket Vault has established a secure Internet session.  (The computer and the Pocket Vault actually establish dual secure sessions in parallel on a standard dial-up or better Internet connection with the Pocket Vault website or the website of an authorized Pocket Vault dealer (for example, a major credit card issuing bank).   The consumer is directed to remove the Chameleon Card from the Pocket Vault slot and to one-by-one dip their existing mag-track cards into the Pocket Vault slot.   These actions do not directly result in the information being loaded into the Pocket Vault or the Chameleon Card, but the information is read, encrypted and sent out over the Internet for verification.  The information is then verified with the original card issuers that all cards the consumer is attempting to load are owned by the person doing the loading and are active cards in good standing.  If the card information passes the verification test, the card info is then remotely loaded onto the Pocket Vault, without further action by the consumer.  If one or more cards do not pass the verification test, a notification message is put up for the consumer.  Cards cannot be added in any other manner.  The security and simplicity of our loading process are two of the elements that impressed card industry executives.


Please feel free to post this information.  You are one of many that has asked such questions, and we are unable to answer all of them.  We hope the flood of orders we are seeing at www.ChameleonNetwork.com (and hope to continue to see) convince card industry executives that we have something here of broad interest to consumers, which could accelerate our efforts.

Regards,

Todd


Todd O. Burger
President & CEO

Chameleon Network Inc.
30 Monument Square, Suite 300
Concord, MA 01742-1858

A cool product and a hands-on company. Definitely a new entry on my wish list.

Posted by erobillard | with no comments
Filed under:

Last week I wrote an EventHandler for SharePoint Team Services 2003 to route files reaching a particular document workspace into the proper folder (based on a string embedded in the filename). While writing it I found a seemingly intermittent quirk with the SPFile.MoveTo() method where sometimes the source file wouldn't be moved (at least it didn't disappear) and a 0-byte file was created at the target Url with the same name. Rewriting this as a CopyAndDelete() method seems to have solved it:

Public Sub CopyAndDelete(ByVal SharePointEventItem As SPFile, ByVal TargetUrl As String)

SharePointEventItem.CopyTo(TargetUrl, True)

Dim fc As SPFileCollection = SharePointEventItem.ParentFolder.Files

fc.Delete(SharePointEventItem.Url)

End Sub

My end-goal worked out pretty well. A user can walk up to any photopier in a branch, drop in a document, select a particular e-mail address from the list, name the document, hit Start and the document magically appears in a Client's individual folder within a SharePoint team site. The same process could be applied to attachments e-mailed from the outside world. 

These articles contributed to the solution:
- Mail Enabling SharePoint Document Libraries
- Creating Event Log Messages for a Document Library in Microsoft Windows SharePoint Services

 

After finishing Neal Stephenson's Cryptonomicon last week I was surprised to find that the Pontifex algorithm it describes was not yet implemented for .NET. So, I present two C# versions of Pontifex: as a fat commented .aspx page and as a lean class assembly. Both include source, and both are linked from the demo page. Consider these to be under the Lesser GNU Public License (LPGL), I'll be adding the appropriate text in the next version of the files.

See the demo.

Read about the algorithm.

 

Posted by erobillard | 5 comment(s)
Filed under: ,
More Posts