@MSGID:
<1546db46-2c70-447c-ad20-622feef8ee56n@googlegroups.com> 0bcd8d20
@REPLY: 1@dont-email.me> d1773d8c
@REPLYADDR stk <skuhagen@web.de>
@REPLYTO 2:5075/128 stk
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<cfef6de1-b912-42d3-9fa7-5d58e911bd66n@googlegroups.com> 1@dont-email.me>
@RFC-Message-ID:
<1546db46-2c70-447c-ad20-622feef8ee56n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
Thanks for your inputs!

Rich schrieb am Mittwoch, 6. September 2023 um 14:51:41 UTC+2:
> stk  wrote: 
> Personal opinion here, but in every case I can think of where doxygen 
> was used to "autodocument the source" the resulting docs were no more 
> valuable than simply reading the source 

 Well, yes... Of course I was referring to a use case where I
really do the documentation and provide the necessary tags to document my
sources. As also pointed out by Ted Nolan, only when using and and
populating tags with useful contents, the result is good. But that is, what
I`m doing. I`m the kind of programmer, who writes documentation first,
then the code... Habit from working a few decades in safety critical
areas.

> > *Tcl-packages:* 
...
> > The whole package hierarchy did not start at global namespace "::" 
> > but as "myPackage::mod1::...". The idea was, that this way it would 
> > be possible to use "require package" in a namespace and thus use the 
> > whole thing not in global namespace but where convenient. For 
> > refactoring I`m now considering, if starting globally as 
> > "::myPackage::mod1::..." is better or not? Is there a best practice 
> > regarding that?
> I don`t think this will matter much. Most scripts do their package 
> requires at the top level of the initial script and so they are "at 
> global level" anyway. Not forcing global level makes the package 
> slightly more flexible, but perhaps a documentation note of the 
> fexibility would be in order.

 Maybe you`re right here. I may overthinking this, because I see so
much cluttered global namespaces in different programming languages by
unexperienced programmers and wonder, what the good Tcl-gurus do with their
packages usually, or what is considered good practice in the community.

> > *Rivet vs. Standalone:* 
> > This is almost decided, but maybe you have some good input here: I 
> > think, I will get rid of using Rivet-apache-module.
> I feel that if you do so you will find yourself eventually adding back, 
> as custom code you have to write yourself, much of what Rivet provides 
> to you if you go this route. 

 True, but it makes the system usable as generic static
document-generator. It currently can only produce pure text, LaTeX and HTML from
different markdown-flavours, but that might change.

> If that is what you want, then go for it. But if your focus is the 
> blog system, not the underlying web plumbing, then keeping Rivet may 
> prove better in the end.

 Rivet will definitely better be integrated into Apache, that`s for
sure and safe a lot of effort. But then I`m also tied to Apache and
have bigger effort making it work with other httpd.

> Tcl has a very useful [time] command. Test, on your hardware and with 
> your code the performance of both and see what you get. Then you won`t 
> be guessing, but will have actual data.

 True, of course. I will measure a few alternative designs as I did
in the first implementation as well. It was a more a broader
consideration. Timing might be one aspect, but also elegance of the design and
resulting API.

Thanks again for your thoughts.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441