So the session was hampered by some corrupted data on the USB sticks, and was more a loosely guided tour of the stack than anything else. I had PostGIS up and running, but could not get my data (loaded into ArcSDE on PostgreSQL using the PostGIS datatype) to load into GeoServer. Tried some other data, and same problem. Unclear what the issue is.

Many of the sample SLD's would not validate (hence could not be loaded), and I could never get the WMS group layers to work. I did get some data up in Google Earth, and open layers, but overall this session confirmed for me that the open source stack learning curve is steep from the get go. I need to get into OpenLayers as the demo's were pretty cool but until I can get the back end all working smoothly it's somewhat moot.

I think that the docs for this will be up somewhere. The software installers are below.

Downloads: http://files.opengeo.org/where2/stick/software

The Javascript API is based on Dojo. ESRI has created some dijits for a map, and the basic pattern looks really similar to the Virtual Earth maps.

The Google Maps extended is just more javascript which extends the base GoogleMaps API to play nice with the ESRI services.

2D and 3D in Virtual Earth is also fully supported - again via javascript extensions.

Slightly different syntax across the APIs, but same basic patterns.

Embed maps and tasks into sites

Use ArcGIS Online or custom (ArcGIS Server) data sources.

Any supported projection. So you polar explorers are now in luck.

Javascript can be hosted by ESRI (like VE or Google Maps) and is in the Akami cloud (think fast, and globally cached - a nice touch).

Samples will be hosted in a live server. Much easier to dig into the samples because they are live. Can copy paste code into your html/aspx/??? file and start modifying. Very streamlined development cycle.

Examples working with a Dojox.grid (Nice because it takes a DIV as a target so the page layout is pretty smooth)

http://maps.esri.com/agsjs/surfaceprofile.html - surface profile demo

InfoWindow can contain whatever you want - i.e. another map

Symbology Model

Really nice demo of a symbol manager based on dojo controls. Incidentally it was running in FireFox on a Mac. Lots of options re: how client side features are displayed. Should be relatively easy to allow client symbolization. Again - looks very performant. They also have symbol sets. They will have a code-gen tool that will allow you to use this tool to setup your symbology, and then export the code to drop into your app. Also running in Safari. Only Solid_Fill supported in FireFox 2. All the saucy picture fills are supported in FireFox 3.

Again stressing the simple, but you'll need to have your CSS, HTML and Javascript chops in shape.

Virtual Earth Extender

Only Tiles - no dynamic layers, but all results can be sent back as VEShapes. Also an interative SDK. Looks just like the VE Interactive API. Javascript hosted by ESRI.

Google Maps Extender

Tiled layers or dynamic layers (via GGroundOverlay). The extender allows you to easily pump results back into GM. The Extender removes the need to convert between the native classes in the base API and the ESRI javascript API - i.e. you can pass a GM LatLongBound into a query. This should be a very smooth developer experience. 

Mapplets

Run within Google Map web site. Can be published to Google Maps. Pretty cool way to push stuff out.

Thoughts:

Again - this is really great stuff. Simple stuff is really easy, and I'm betting that the hard stuff is still difficult, but I'd wager it's miles better than the 9.2 ADF experience. We'll see what the 9.3 .NET ADF has in store at tomorrows session...

The information flow here is very important - design the application to show focused data in small chunks. This allows very small, fast transactions. That said, if you try to push tons of data into your browser, it will bog down.

Since the Javascript is hosted by ESRI, presumably anyone can just include it on a page. From there, you can consume the free ArcGIS Online services, and of course you can mash-in anything else you want. So it would see that there is a world of good free fun just waiting to be explored...

Just saw this over on Omar Shahine's blog, and had not noticed it on the GIS feeds. This thing is very cool. Data coverage is limited to downtown San Francisco and Seattle, and the usability is a little "eh" at this point,  but I like it better than A9's option, but I just noticed that you can bookmark a location at A9, but not on this version of the Local. In any event, Microsoft is really getting their browser-based-map-thing game on.

So - I need to facilitate emailing a map from a custom .NET ArcIMS site. (built on DotNetNuke - screen shot below)

 In .NET we conventiently have the System.Web.Mail namespace and objects to help out with this. It's almost trivial to use...

Dim Email As New MailMessage
Email.To = "address@something.com"
Email.From = "from@something.com"
Email.Subject = "Hello"
Email.Body = "This is the email."
SmtpMail.SmtpServer = "localhost"
SmtpMail.Send(Email)

The issue is how to attach a map. There is an Attachemet object, but it only supports attaching FILES. So you say - big deal - ArcIMS has created a .gif file, just send that. Well, that's cool if ArcIMS is on the same physical machine as the .NET app, or if you can map a drive to ArcIMS's output location, but what happens when that's not possible? i.e. you need to retreive the map from the output location, and then attach it. Ideally you do this by loading the image from the URL using a WebClient object (this is easiest, maybe not fastest)...

Dim webC As WebClient = New System.Net.WebClient
Dim OutputBitmap As Bitmap = New Bitmap(webC.OpenRead(http://myims/output/map2.gif))

Great. Now I can save the bitmap out to a file, and attach it. Which is what I've done for v1 of this tool. The downside is that you need to setup a directory that your ASP.NET application can write to, and can clean up. This is a lot of work for very little gain. Would'nt it be great if you could just create an attachment from a stream?

Well, apparently there are a bunch of commercial SMTP components which can do this, and while I'm not against them, I can't legitmize $200 per server for this little function - so I looked for some open source stuff. I found some classes that send messages via SMTP without using System.Web.Mail - they get all old skool and speak SMTP and use TCP sockets. So this is the first part. They're mostly C# (and I'm a VB.NET kinda guy), but I may go ahead and extend them to support adding attachments via streams. We'll see if I need this, but wanted to write it up anyhow...

Resources:
ComponentSpot is a great place for FREE components. Here are two SMTP projects
 
VB.NET Sending SMTP using Sockets

C# SMTP Mail without using SMTP Service or CDO (which is behind System.web.Mail)