Thanks everyone. I got about 20 MMS and SMS messages to figure out how to support these types of emails for dasBlog. I actually found a few minor bugs in the Mail-To-Weblog support and while the messages of course don't come out as pretty as from a regular email client, it does at least work now.
What's key -- and that's something that I can't figure out a consistent workaround for -- is that the SMS/MMS gateway must be capable of setting a subject line for emails so that dasBlog can do it's passphrase check. For Germany, this page has a bunch of info on how that works in the major networks (in German).
Yesterday and today I have added another new feature to dasBlog called "Crossposting". This feature, which will be available in the v1.4 build that I still plan to publish before the Microsoft PDC next week, is simplifying having multiple blogs on several sites by allowing a entries to be posted to a master weblog running dasBlog and having the engine crosspost across multiple weblogs using the Blogger API or the (more powerful) MetaWeblog API. If the entry is updates locally, the crossposts are updated and if the entry is deleted, the crossposts get wiped, too.
My concrete problem was that I wanted to contribute to longhornblogs.com, but didn't want to maintain a separate blog. Now I can post a local post here, check a checkbox and it'll appear in both places. To still get the referrals, I am "bugging" the crossposted articles with a transparent GIF that phones home into the referrer stats of the main blog.
I'll post a "how to" along with the release, which I hope will happen by Friday. Until then, you can check that it works by looking at the three synchronized weblogs.
One thing that’s still on my list of things to add to the Mail-To-Weblog support of dasBlog is support for SMS and MMS blogging. Because SMS and MMS e-mails routed through the mobile phone carrier’s E-Mail gateways often seem have varying whacky formatting added to them either by the phone itself or by the carrier (like weird subject lines), I need to have a set of samples to figure out how to support this best.
If you have E-Mail via SMS/MMS enabled for your phone and are willing to make a small donation to the dasBlog project by sending one E-Mail to me, you could help me getting this feature right. The E-Mail should have the subject “DasBlog:SMS” or “DasBlog:MMS” (if your phone permits that) and the text body should contain the mobile carrier name, phone manufacturer name and model number. Of course, MMS is where the real fun is and what I want to support fully.
Once we’ve got support for inbound SMS/MMS blogging, I intend to support WAP and cHTML support as well as a special set of templates and entry points for small form factor browsers like PocketPC in the following version.
E-Mails should go to clemensv@newtelligence.com
I wasn’t sure how good these two new features would work, but the
stats are so great that I already don’t want to miss them. Gives you a
really good impression what people are (still) interested in and what files
they grab from you site. Now I finally know what stuff (code, PPTs) I need to
keep current and what I topics should come back to and revisit.
For the curious I’ve included two screenshots of what today’s
stats of these two features look like as of 10 minutes ago.
I've bumped up the version number for dasBlog to 1.4. I've got a couple of enhancements myself in a private build here and the folks over in the workspace at GotDotNet have added quite a few cool things as well. I want to check in my new stuff before end of next week, so that we'll have an "official build" ready just before PDC.
The two features I added today are evil spy-features "ClickThrough" and "AggBug".
ClickThrough is an automatic mechanism that will (if configured) replace all hyperlinks in your web-page content with references to a redirector service, which logs clicks. So you'll learn which links people actually click. I added this mostly because I am curious about my downloads.
AggBug (long version: "RSS Aggregator Web Bugs") injects a reference 1x1 transparent GIF into the HTML that's emitted by the RSS generator for each entry. The GIF is served by the engine itself and tracks those requests. I am doing that, because I really want to know how many readers I have. Currently I only see the readers who are coming to the web-site, but I suspect that the vast majority are using aggregators.
Update: I should probably add that I am not logging IP addresses in these two features just as I am not doing that with referrers.
While you wait for the Indigo show to start, here is some stuff to look at and consider (again).
The links at the bottom of this post point to five slide decks that I have been using for presentations throughout this year. All of them are, indeed, very relevant to the Indigo story you will be hearing at PDC 03.
This spring, I’ve been on the road together with my good friend Steve Swartz, who is one of the Architects and Program Managers at Microsoft’s Indigo Team. On this tour, we have presented lots of ideas around scalable applications in seven cities all over Europe. And of course, we knew at the time that Indigo was coming … ;)
The “DistSys” ZIP files below contain the four decks we have been using on that tour. “Layers” is about layering, tiers and services (pay attention to “dialogs”), “Processes” is about implementation aspects such as process models, state and sessions, “Transactions” is about taking thinking about transactions beyond the database and “Scaling” highlights several essential ideas around scalability.
My DEV357 talk at TechEd Dallas, which is in part an aggregate of the talks from this tour, may even be more important, because it actually contains outspoken, concrete guidance for how to build applications on today’s technology stack in order to be ready for Indigo. To summarize the core message of that deck in terms of appropriate use of the existing technology stack for distributed systems:
· .NET Remoting: Use for “local”, on-machine, cross-app-domain communication.
(In clear words: Remoting calls don’t leave the machine!)
· Enterprise Services: Use for “near”, cross-process, cross-machine communication
· ASMX: Use for “near” or “far”, cross-process, cross-machine communication. Prefer over Enterprise Services, unless you need the features or have pressing performance problems.
Read. Understand. Absorb.
Download: DEV357-CV-Building-Distributed-NET-Apps-V2.zip
Download: 1-DistSys-Layers-Swartz-Vasters-V8-complete.zip
Download: 2-DistSys-Processes-Swartz-Vasters-V6-complete.zip
Download: 3-DistSys-Transactions-Swartz-Vasters-V9-complete.zip
Download: 4-DistSys-Scaling-Swartz-Vasters-V6-complete.zip
Grosse Dinge steht vor der Tür, alle wollen hin. Problem: Die ganze Operation ist nicht gerade billig und der Chef läßt einen nicht hinfahren.
Um ein bisschen Trost zu spenden und auch um einen netten ersten Anlass zu geben, sich unter (nieder-)rheinländischen Entwicklern mal zusammenzusetzen ohne dass es gleich was kostet, haben wir hier bei newtelligence vor, sehr kurz nach der grossen Microsoft Veranstaltung in L.A. irgendwo hier bei uns einen Saal zu mieten (irgendwo rundum D, MG, NE) und unter dem Motto "Neues aus L.A." in ungefähr 3 Stunden, ganz informell und bei einem gepflegten Bierchen die wichtigsten Stichpunkte von dem was wir an Einsichten mitgebracht haben für den programmierenden Rheinländer zusammenzufassen.
Wenn wir genug Kölner und Bonner zusammenkriegen machen wir auch sehr gerne einen zusätzlichen Ausflug auf die Südseite der Worringer Linie. Die Veranstaltung soll und wird nichts kosten und wir kennen sogar jemanden, der bereit ist ein oder zwei (oder drei) Lokalrunden auszugeben.
Also, wer Interesse hat oder wer einen kennt der Interesse haben könnte, hier sind die Eckpunkte:
- Termin: irgendwann in der Woche vom 10.11. bis zum 14.11; Start so um 18:30. Endgültig festgelegt haben wir ausser dem Ausschluß vom Hoppedizerwachen (11.11.) noch nichts. Kommt auch drauf an wann die meisten Interessierten können und was wir für eine Lokalität brauchen. Unsere Favoriten sind aber Donnerstag und Freitag.
- Themen: WinFS, Indigo, Avalon und ASP.NET 2.0
- Ort: Altbierzone D, NE, MG und ggf. zusätzlich nochmal in der Kölschzone K, BN, BM
- Vortragende: Willers, Freiberger, Vasters
- Anmeldung von Interesse: Bitte per EMail (training@newtelligence.com) mit dem Betreff "Neues aus L.A.", mit Name und Adresse/Kontaktinfos und bis allerspätestens 24.10. damit wir das auch organisatorisch noch hinkriegen. Und da wir weder die Kölnarena noch die Philipshalle mieten werden, müssen wir natürlich irgendwann auch die Tür zu machen. ;)
- Grund: Künne mer donn, also dommer dat.
Weitersagen.
China has a man in orbit. I think that's fantastic. I strongly believe that they're serious about going to the moon. It's time man goes back up there.
Here’s a little, so far unpublicized secret from my calendar (read on, freebie ahead):
My company, newtelligence, is currently running a series of workshops on “Windows DNA to Microsoft .NET migration” for Microsoft EMEA at the Microsoft Technology Centre in Reading, UK. We already ran three events with lots of success and have at least another two scheduled.
On the first day, we cover aspects like “Why, when and when not to migrate”, migration strategies, Web services integration and side-by-side comparisons of technologies like ASP/ASP.NET and ADO/ADO.NET. And on the second day, we actually port an ASP/COM+ app to the .NET platform from scratch and show common preparation steps, pitfalls and workaround techniques.
And here’s the best of it all: Microsoft offers this workshop series to their enterprise customers at no charge. All you need is to register and pay your own travel and hotel. The events run at the Microsoft Campus in Reading, UK. Next dates are November 6-7 and December 11-12. Seating is very limited, so if you are interested you need to be quick to grab a seat.
There are two ways to get in. Either contact your Microsoft account manager (if you have one) and ask about the “DNA -> .NET Interop and Migration” course at the EMEA Microsoft Technology Centre or, much simpler, simply drop us a mail at training@newtelligence.com with your full business contact details and we’ll get back to you with the full agenda and information on how to sign up (given there are still seats available). If you don’t think you are a Microsoft enterprise customer – write anyways. We’ll try.
Why am I writing this? At the last run of the event we still had a few seats left and I suspect that was simply because only few people knew about these events and Microsoft didn’t make them very visible. So I thought I should make that a bit better known for the benefit of the community ;)
Now you know. Tell your friends. It’s good, it’s free, can’t go wrong ;)
I see quite a few models for Service Oriented Architectures that employ pipelines with validating "gatekeeper" stages that verify whether inbound messages are valid according to an agreed contract. Validation on inbound messages is a reactive action resulting from distrust of the communication partner's ability to adhere to the contract. Validation on inbound messages shields a service from invalid input data, but seen from the perspective of the entire system, the action occurs too late.
What I see less often is a gatekeeper on outbound channels that verifies whether the currently executing local service adheres to the agreed communication contract. Validation on outbound messages is a proactive action taken in order to create trust with partners about the local service's ability to adhere to a contract. Furthermore, validation on outbound messages is quite often the last chance action before a well-known point of no return: the transaction boundary. If a service is faulty, for whatever reason, it needs to consistently fail and abort transactions instead of emitting incorrect messages that are in violation of the contract. If the service is faulty, it must consequently be assumed that compensating recovery strategies will not function properly and with the desired result.
Exception information that is generated on an inbound channel, especially in asynchronous one-way scenarios, vanishes into a log file at a location/organization that may not even own the sending service that's in violation of the contract. The only logical place to detect contract violations in order to isolate and efficiently eliminate problems is on the outbound, not on the inbound channel. Eliminating problems may mean to fix problems in the software, allow manual correction by an operator/clerk or an automatic rejection/rollback/retry of the operation yielding the incorrect result. None of these corrective actions can be done in a meaningful way by the message recipient. The recipient can shield itself, and that is and remains very important. However, it's just a desperate act of digging oneself in when the last line of defense did already fall.
|