This project is read-only.

Author Profile Provider

Topics: Business Logic Layer
Apr 3, 2009 at 1:30 AM
I am attempting to integration your very cool tool into an existing web site with users. I was already using the ASP.NET membership and role providers which plugged into blog engine almost perfectly. The only bit that did not work was the user (AuthorProfile) part.

I was curious if there are plans to separate the AuthorProfile parts of the BlogProvider into an independent, say AutorProvider or maybe a System.Web.Profile.ProfileProvider?

Apr 3, 2009 at 10:48 PM
I have another question regarding this, as I decided to create a new DBBlogProvider, based on the original, then just override the profile parts. This, I think will "work", however, it looks like all of the data in the profile table is loaded into memory at startup.. Actually, it looks like all of the data is loaded into memory at application startup?
Apr 3, 2009 at 11:19 PM
Yes, the first time a profile needs to be accessed, all the profiles get loaded from the datastore and stored in the static list of AuthorProfile objects (_Profiles).  The profiles can be updated in the datastore using the GetProfile and Save methods.
Apr 5, 2009 at 1:25 AM
Hmm.. thanks for the response. How well does this approach sacle, to say 100,000 or more profiles?
Apr 5, 2009 at 1:37 AM
It wouldn't scale very good :)  But 100,000 profiles isn't very realistic for most people.

Most data in BE is actually retrieved once and stored in memory.  An even better example of scalability problems is blog posts.  Blog posts are read once and stored in memory.  Once you start writing 100, 200, 300, 1000, 2000, 3000 blog posts, BE is going to be consuming A LOT of memory.

Mads brought this up last year in this blog post.  AFAIK, scalability in BE still needs to be improved.  Caching can really help -- when done right.  There are some pretty good ideas on caching in that blog entry and the comments that follow.

But for items where there isn't typically a large volume (categories, blogroll, maybe profiles), caching generally makes sense.
Apr 5, 2009 at 6:07 PM
I think I will be able to live with the blog parts working as they do now, but the profile part will need to change if I am to use this tool. That said, if I separated out the profile aspects of the blog provider and maybe implemented that as a System.Web.Profile.ProfileProvider, any chance of getting that incorporated into the main blog engine baseline.
Apr 5, 2009 at 7:31 PM
I can't make any promises, but I don't see any reason why BE couldn't incorporate a Profile provider.  Especially since ProfileProvider is already a part of ASP.NET, it would make some sense to piggy back onto that existing architecture.
Jul 15, 2009 at 11:28 AM

I've just had confirmation that kgolding chose to go with WP instead of developing the Profile side of BlogEngine!

.NET itself has the very handy:   <anonymousIdentification enabled="true"/>  tag which can prove very handy with website engagement of visitors even if they choose not to register on a site fofr instance,

Such a tag works with a proper Profile provider based on System.Web.Profile.ProfileProvider - So I for one am very interested to see an integration into the standard System.Web.Profile.ProfileProvider

Or   a custom hack.........

What do you think BenAmada,  I'm even happy to attempt it myself with a little guidance provided by an expert in BE

These things would certainly help in BE's attempts at becoming a leading Blog platform IMO.