I'm currently looking into the feasibility (and danger) of exposing a SharePoint 2007 install on a public website in an extranet-type scenario.
While there's no doubt that Microsoft has greatly improved the security of their products in recent years, I'm still naturally wary whenever it comes to using their systems in an unprotected environment. The other problem with using SharePoint in a public environment is the Active Directory question -- how do you manage identity in a federated environment, especially when not all participants may have Active Directory installed?
Some interesting resources I've discovered to date include:
Completely irrelevant to anyone or anything, except perhaps as a commentary on the strangeness and inventiveness of the human brain.
Ladies and gentlemen, I present the dorodango.
A number of people have described methods for private variables and methods within JavaScript.
In that spirit, this is another possible template. The main difference between this version and most others is that it uses the concise JSON notation for variable and method declarations.
File.Writer = File.Writer || function (filename, append, binaryMode) { Not a new phenomenon, of course, but it's nice to know that the problems of groupthink on the Internet are being seriously considered.
I'm really getting into XSLT -- it's a very powerful way of manipulating XML, but it still seems crazy to me that there's no easy way of getting regular expression support given how much of XML data is, you know, text.
Ah well -- at least Xalan has a good support mechanism for extensions. How about some JavaScript RegExp goodness? This page and this page outline a method to get it working, but there's currently unspecified weirdness which is annoying me.
Clamshell is an OpenID server implementation I have developed as part of ongoing work at building my own wiki software.
It's very simple and is really just a re-modularization and extension of the phpMyID single-user OpenID software.
But it tests out OK as a compliant implementation of the OpenID 1.1 spec and may prove useful to others. (For those who don't know what OpenID is, think of a decentralized implementation of the Passport or Liberty single-sign on systems.)
I've long been fascinated by the eXist native XML database, and I think it's just made it into my list of apps that can really help an enterprise out.
Why? Well, I think in the Web 2.0 days there's a clear shift away from aggregated data sources to document-driven workflows. But there's still a need to search, run queries, and limit access to these documents.
Plus eXist belongs to the WebDAV world. That means REST: you can add, update and delete documents from eXist just by issuing the right HTTP command. The icing on the cake is that by making a couple of simple changes to an XML 'collection' (think: collection = database) you can turn it into fully fledged Atom feeds with full APP support. Mmmmmm.
Okay, compiling my own stack has already frustrated (and scared) me to death before, but this set of instructions seems almost simple enough to follow:
Set up the Command Shell for Windows 2000/XP/2003
Building Perl
Building Apache with SSL, Security & Compression
Building OpenSSL
Building mod_perl 2.0.2
Perl's looking a little long in the tooth these days -- there are so many more exciting languages out there, like PHP, Python and Ruby. But there's still an enormous wealth of programs being written and updated on CPAN, and Perl still excels at the text-based manipulation which it got famous for.
If Perl 6 ever comes out, that may be interesting, although I'm still unsure of the impact of all the syntax and keyword changes. Seems even more complex than before!
On the other hand, I just found out about the PAR-Packer tool, which allows you to easily convert any Perl program into an EXE file. Previously, the only easy method to my knowledge was the proprietary perl2exe tool from IndigoStar.
Then check out xFront, and particularly their article XML Schemas: Best Practices.
(UPDATE: Their Design Goals Questionnaire is also really useful.)
Practical advice from the xml-dev mailing group, so these people do it every day.
