Re: [repro-devel] WebAdmin domain
Hi Ruslan,
Did some more digging around and have some more comments:
1. You can disregard my question 3 below - I see why you are using the
Notice log level, and it is only for two log lines related to running
repro as a windows service. I think this is fine.
2. I completed part of #2 from email below (removed domain and route
settings from parameters), but think it would be nice to add the ability
to show the current default settings for any non-set parameters.
3. I updated the VS2003 project files - However I didn't update the
installation package to work like the vs2005 setup does.
4. I updated the linux makefiles.
5. You've modified the way the admin password is used (I think), so
that it is no longer using the admin user from the UserStore. This
change is not backward compatible with the old release, and should be
adjusted. Essentially the command line parameter for admin password was
intended to only be used once, to originally set the password. This
would cause the user to be created in the UserStore, then the command
line arg is no longer required, except to change the pwd. One option is
to just revert this code to it's old form, but it is nice to be able to
set/change the password via the web gui. Ideally - changing the
password parameter on the web gui causes the admin entry in the
userstore to be updated. This gives us the desired functionality and
maintains backwards compatibility.
6. The problem happens for the Interfaces setting, but may also happen
for other settings. I tried setting the interface setting to some value
and then pressed the re-start button - Repro restarted and used this new
setting. I then wanted to revert back to the default behaviour - so I
cleared this setting and pressed the re-start button. But the old
settings continued to be used. This should fixed.
7. #4 (from email below) is still a backwards compatibility issue that
needs to be solved before merging with mainline.
8. You should merge the latest changes from SVN head into your branch
sometime soon, since there are some config changes - this will make the
merge back into main less painful later.
My time is limited. Are you able to tackle these outstanding items?
Others, please have a look at what's in the branch. When these
outstanding items are covered, I think we will be able to merge with
main. Let me/Ruslan know of any concerns.
Cheers,
Scott
> -----Original Message-----
> From: repro-devel-bounces@xxxxxxxxxxxxxxx [mailto:repro-devel-
> bounces@xxxxxxxxxxxxxxx] On Behalf Of Scott Godin
> Sent: Friday, November 30, 2007 5:16 PM
> To: Ruslan Radvansky
> Cc: repro-devel@xxxxxxxxxxxxxxx
> Subject: Re: [repro-devel] WebAdmin domain
>
> Hi Ruslan,
>
> I finally got some cycles to start reviewing your changes. Overall
> things look great - these are very useful additions to repro! Thanks.
>
> Some preliminary comments/questions:
>
> 1. While reviewing the code I made some formatting changes - mainly
> revolving around the case used for method and variable names. Some
> general rules that are followed in most of the resip code:
> - method and local variable names start with a lower case letter
> - all if statements contain bracketing on a separate line
> - member variables always start with a lower case m followed by an
> upper case letter
>
> 2. Parameters
> - we should remove the domains and routes settings from the
parameter
> table, there are already separate pages to configure these in repro -
> the command line options where just there to be able to start repro
> completely from command line without every pre-configuring from the
web
> interface.
> - It would be good if the parameters page showed the default values
-
> perhaps we should load the parameters table with all of the compile
> time
> defaults at startup - thought?
>
> 3. Why is the new Notify log class needed? This may be confusing for
> linux implementations.
>
> 4. Backwards compatibility - Current repro windows users will likely
> have their berkely db files located in the same directory as the
binary
> - if they upgrade to this release - repro will not use them - we
should
> probably fix this, so that if the db files are installed in the exe
> directory or working directory, then they are used instead of using
the
> profile path. Or we could just use the profile paths if we are
running
> as a service??
>
> Thanks,
>
> Scott
>
>
>
> _______________________________________________
> repro-devel mailing list
> repro-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/repro-devel