నా ప్రస్తుత ప్రాజెక్ట్, వినియోగదారుల ప్రపంచవ్యాప్తంగా ప్రయాణం మరియు వారు విభిన్న గమ్యస్థానాలకు వద్ద వచ్చినప్పుడు, use whatever machine is handy at the time. Those guest machines will be running Windows and installed and configured for the local locale. (I’ve just realized that the guest machines may not have the right language packs… probably won’t, నిజానికి… I’m parking that one for now).

SharePoint needs to provide a mechanism whereby the user can pick their preferred language and then have MOSS honor that language regardless of how the user accesses MOSS. In other words, disregard whatever the browser tells IIS/MOSS and instead look up that preferred language and use it.

We’re going to investigate two approaches:

1. HTTP Handler: A custom HTTP handler installed on IIS will look up the user’s MOSS profile, figure out the preferred language and then switch the HTTP header around as needed before passing control to MOSS.
2. global.asax: Modify global.asax to do the same thing. We may modify something else, but the idea is that we find some place where we can insert our locale-switching logic.

The other complicating factor is that we need to support 60k users, గురించి 1,000 of which may be simultaneously accessing MOSS at peak load.

The HTTP handler seems pretty drastic, but possibly the best place to put the code since it’s at the IIS level and all-knowing. It’s a good single point of work.

We’re leaning toward a global.asax type approach, mainly because we believe we’ll have more options for caching data at that point.

I’ll be blogging more on this subject as I learn more.

If you have know anything about this, please post a comment 🙂

</చివర>

నా బ్లాగ్ సబ్స్క్రయిబ్.

వద్ద ట్విట్టర్ లో నన్ను అనుసరించండి http://www.twitter.com/pagalvin

I’m on a project where we need to collect metrics around a function named "Share a Story." The idea is very simple — మీరు ఇంట్రానెట్ పై ఒక ఆసక్తికరమైన వ్యాసం చూడటం మరియు ఎవరైనా దాన్ని భాగస్వామ్యం చెయ్యాలనుకుంటున్నారా చేస్తుంటే, click a link labeled "Share this story" మీ స్నేహితుని ఇమెయిల్.

మేము ఈ ప్రయోజనం కోసం ఒక కస్టమ్ రూపం తో చుట్టూ వాయించే, కానీ అంతిమంగా, ఇంగితజ్ఞానం రోజు గెలిచింది మేము కేవలం తెలిసిన ఉపయోగించడానికి <ఒక href = mailto:…> technique. (<ఒక href mailto:…> HTML యొక్క ఒక ఆశ్చర్యకరంగా బలమైన కొద్దిగా ఉంది; ఒక బోనస్ గా, ఆ లింక్ నా పాత UNIX man పేజీలను రోజుల నన్ను తిరిగి తెస్తుంది; ఆ రోజుల్లో ఉన్నాయి!).

వారు వారి తెలిసిన MS Outlook క్లయింట్ ఉపయోగించడానికి పొందటంతో ఈ టెక్నిక్ తుది వినియోగదారుల కోసం ఒక గొప్ప ఇంటర్ఫేస్ను అందిస్తుంది (లేదా సంసార ఇమెయిల్ క్లయింట్ వారు ఇన్స్టాల్).

ఇది పేద డెవలపర్ రకాల మమ్మల్ని విషయాలు కఠినతరం చేస్తుంది ఎందుకంటే క్లయింట్ * కూడా * కథలు తరచుగా భాగస్వామ్యం ఇది ఎంత తరచుగా వినియోగదారులు భాగస్వామ్యం కథలు కూడా చూపే భవిష్యత్తులో ఒక నివేదిక అమలు కోరుకుంటున్నారు.

We whiteboarded a few potential solutions. My favorite is to carbon copy (CC) a SharePoint list. That way, the end user still gets the outlook client while we get to capture the event because we’ll get a copy of the email ourselves. There are some obvious drawbacks. The main problem is that the user could simply blank out or otherwise mangle the CC address. మరియు, we need to manage that event library of emails. We have a scheduled job on the white board responsible for that cleanup.

మీరు ఈ సమస్య పరిష్కారానికి కొన్ని తెలివైన పద్ధతి కలిగి ఉంటే, చెప్పండి చెయ్యండి.

</చివర>

నా బ్లాగ్ సబ్స్క్రయిబ్.

వద్ద ట్విట్టర్ లో నన్ను అనుసరించండి http://www.twitter.com/pagalvin