The source code archives (SourceSetup/SourceZip) are missing four files in the Assemblies subdir that the gentlemen who added the respective features didn't care to put into the source setup project. You can get the files either from one of the other distribution archives, from the GDN workspace (source control) or the fixed source code archives from the dasBlog download location. GotDotNet doesn't let me upload the corrected release version right now, so I deleted the source release copy over there for the moment.
newtelligence dasBlog v1.4: After you have read the release/upgrade
notes, get it from here.
I have done a bit less testing than I usually would, because I wanted to get
this version out in time for PDC – just because I want to have some of the
new features (especially cross-posting) for myself for PDC. I have bravely
deployed this new build on my own blog (here) and it didn’t break me, so
it should work for you as well. Make a backup of your site before you install,
ok?
Cross-posting is certainly the coolest feature if you happen to have two or
more blogs (the number of folks who have that is growing daily). Before I add a
formal explanation to the docs (which isn’t going to happen tonight) here’s
a quick primer:
If you have cross-posting enabled on the configuration page, you will have
two more entries in the administrator bar. “Crosspost Referrers”
and “Crosspost Sites”. Crosspost sites is an editable list where
you can enter the other blogs you want to post to and where you want to keep
entries synchronized. The picture shows my setup for Lonnghornblogs.com.
Hostname and Port should be trivial to understand. The “Endpoint”
is the Blogger API or MetaWeblog API endpoint of your blog engine (leading
forward slash required). It’s tested that dasBlog interops with itself
;), with .Text and Blogger.com. There’s not much of a reason why it
shouldn’t interop with more engines. The API type is either “Blogger”
(for Blogger.com) or “MetaWeblog” (for mostly everything else,
including dasBlog and .Text). Click the “Test” button to verify the
setting before you save them.
Once you’ve set up one more more sites, you’ll get the following
little extra box at the bottom of the “Edit Entry” page:
Just check the sites you want to cross-post to. If the site supports the
MetaWeblog API, you can also enter categories there. Multiple categories are
separated by semicolons. Once you post, the cross-posts are queued up and will
be posted within a couple of seconds. One catch: You should no re-edit the
entry before the synchronization is done; typically within 15 seconds after your
post has been stored. If the entries haven’t been synchronized, yet, the
checkboxes will remain unchecked.
If you subsequently edit the entry, the changes will be replicated into the
foreign Weblogs (not vice versa). If you delete the entry, the foreign entries
will also be removed. In essence, you only have one blog to maintain, but
multiple publishing points.
The feature isn’t yet integrated with Mail-To-Weblog. What you need to
do there is to post your entry via mail, edit the entry later via the web
interface and change nothing except checking the appropriate boxes and setting
the categories. Support for cross-posting via Email will be in v1.5.
The “Crosspost Referrers” page shows the referrers that you are
getting on the foreign site. Note: Your main blog is going to get some
of the traffic of the foreign blogs because of the referrers feature. The
referrer stats are baked into the cross-post feature and can’t be switched
off singly at this time. For each unique hit the foreign site gets on one of
your entries, there’s a potentially a request for a 43 byte image plus a
bit of protocol overhead; let’s make that 100-150 bytes. Keep that in
mind before you enable cross-posting to a high traffic site, otherwise this
feature may end up “slashdotting” your own server. (Similar considerations
are true for “Aggregator bugging” – see the release
notes)
PS: Thanks to all the heroes in the GDN Workspace who helped a lot with this
release.
Brad More is asking whether and why he should use Enterprise Services.
Brad, if you go to the PDC, you can get the definitive, strategic answer on that question in this talk:
“Indigo”: Connected Application Technology Roadmap
Track: Web/Services Code: WSV203
Room: Room 409AB Time Slot: Wed, October 29 11:30 AM-12:45 PM
Speakers: Angela Mills, Joe Long
Joe Long is Product Unit Manager for Enterprise Services at Microsoft, a product unit that is part of the larger Indigo group. The Indigo team owns Remoting, ASP.NET Web Services, Enterprise Services, all of COM/COM+ and everything that has to do with Serialization.
And if you want to hear the same song sung by the technologyspeakmaster, go and hear Don:
“Indigo": Services and the Future of Distributed Applications
Track: Web/Services Code: WSV201
Room: Room 150/151/152/153 Time Slot: Mon, October 27 4:45 PM-6:00 PM
Speaker: Don Box
If you want to read the core message right now, just scroll down here. I've been working directly with the Indigo folks on the messaging for my talks at TechEd in Dallas earlier this year as part of the effort of setting the stage for Indigo's debut at the PDC.
I'd also suggest that you don't implement your own ES clone using custom channel sinks, context sinks, or formatters and ignore the entire context model of .NET Remoting if you want to play in Indigo-Land without having to rewrite a large deal of your apps. The lack of security support of Remoting is not a missing feature; Enterprise Services is layered on top of Remoting and provides security. The very limited scalability of Remoting on any transport but cross-appdomain is not a real limitation; if you want to scale use Enterprise Services. Check out this page from my old blog for a few intimate details on transport in Enterprise Services.
ASMX is the default, ES ist the fall-back strategy if you need the features or the performance and Remoting the the cheap, local ORPC model.
If you rely on ASMX and ES today, you'll have a pretty smooth upgrade path. Take that expectation with you and go to Joe's session.
[PS: What I am saying there about ES marshaling not using COM/Interop is true except for two cases that I found later: Queued Components and calls with isomorphic call signatures where the binary representation of COM and the CLR is identical - like with a function that passes and returns only ints. The reason why COM/Interop is used in those cases is very simple: it's a lot faster.]
Doug, you are absolutely going to get newtelligence's PDC T-Shirt, but in all reality you should give me a T-Shirt for allowing you a super smooth transition and perfect upgrade path from your outdated blogging tool to this here. Tell Don that he's going to get one, too, if he makes the switch.
"newtelligence PDC T-Shirt!" you ask? There will be two types. The one Doug is asking for is very on-topic for PDC and it's subtly outrageous. You will have to wait until PDC and catch me (or someone who's got one) to see it.
Of the other one I'll have just three made for myself and it's not really subtle in it's message, but rather conveys it quite clearly:
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.
|