Re: [repro-devel] WebAdmin domain
Ruslan,
Comments inline....
> -----Original Message-----
> From: Ruslan Radvansky [mailto:prostoruslan@xxxxxxxxx]
> Sent: Thursday, November 29, 2007 4:49 AM
> To: Scott Godin
> Subject: Re[4]: [repro-devel] WebAdmin domain
>
> Hello Scott,
>
> Wednesday, November 28, 2007, 3:59:26 PM, you wrote:
>
> >In general we attempt to minimize Mutex use in the stack - I think
> that
> >change will raise some flags.
>
> Currently Security object used only in one thread, or in several? I
> think that at least in two - StackThread and WebAdminThread. And as
> long as I can understand cert server run in context DumThread. If
> Security object dynamically add certificates to own cache we need
> synchronize this.
[Scott] Yes you are right - there are multiple threads using the
Security object. I guess we should analyze if these calls are thread
safe or not and add mutex's. I don't see any other way to protect the
Security data members.
> By the way, if
> we expose
> certificates by WebAdmin (http://localhost:5080/cert.cer) it may be
> security flaw.
[Scott] Why is that a security flaw? Serving certificates is the whole
point of the Certificate Server in repro.
> >Having 2 security objects means having two sets of certificates
> >cached
> in memory.
> >I think we should try to avoid this.
>
> You are right. Currently I see two ways to avoid this.
>
> >Can you describe your architecture goals more clearly? What is the
> purpose
> >of this separation?
>
> I want make easy way for creating servers based on repro code for
> other peoples and for me. We can use C++, use BerkleyDb for database,
> use web-based administration tool and we get repro as is. But anybody
> can use Visual Basic, MS Access as database, reach GUI as
> administration tool and use repro code as dynamic loadable library.
> Therefore I want separate code what I must rewrite/replace and code
> that I need leave untouched. By the way, on main page
> www.resiprocate.org You write that You write code for freely use in
> another commercial and open-source projects. May be You want say not
> only "freely", but also "easy"? ;-)
[Scott] I clearly understand your motivation - I want to understand more
about exactly what you are proposing as changes to repro source code.
Thanks again for helping out,
Scott
> >In my view, architectural changes should be minimized or discussed
> clearly on the
> >list first, in order to have the best chance at integration into the
> main line SVN.
>
> >I was not involved in the original architecture of repro - so I'd
> >like
> to hear
> >others opinions after you have clarified things.
>
>
>
> --
> Best regards,
> Ruslan mailto:prostoruslan@xxxxxxxxx
>