@MSGID:
<cfef6de1-b912-42d3-9fa7-5d58e911bd66n@googlegroups.com> 781b8425
@REPLYADDR stk <skuhagen@web.de>
@REPLYTO 2:5075/128 stk
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
<cfef6de1-b912-42d3-9fa7-5d58e911bd66n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
Hello there and thanks for reading in advance,

Long post... Sorry.

long time Tcl`er here (since about 1992, professionally and privately).

 Context: a few years ago, I wrote a kind of a picture- and
blogging-module using Rivet for Apache-HTTP. Didn`t want to use WordPress or the
like, since I have some specific features in mind and also just for the
fun of implementing it myself...
 I used it extensively periodically over years (since about 2014) and
it got a few new features over time - it "grew"... What started as a
quick hack, got a little messy over time and it would be hard to add a
few serious new features the way it is now. So I`m refactoring,
reimplementing it and now I`m considering some design-decisions for the
architecture, where I`d like to ask the expert-community about your opinion.

*Documentation:*
 I`d like to use Doxygen, but not sure, if this is still a good
option, since Tcl is not supported anymore. Whats your preference? My goal
is, to document the API of my project in source and generate it into
HTML automatically. Previously, Doxygen was my tool of choice here. -
Another option would be to make the system self-documenting, since it will
have parser-plugins and the ability to create document-trees. But why
inventing the wheel, when it`s already there (even, if it`s a flat tyre
nowadays...)? - Are there better ways to create API-docs from sources for Tcl?

*Tcl-packages:*
 The first implementations (there are three at this time...) used
Tcl-packages to split the whole thing into architecture components. A main
package that loaded all the others in its init-part and then provided the
Rivet-Apache-plugin as package which was used in a small Rivet-script that just passed
on the HTTPS-request to my package.

 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?

*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. Although I really like
it and use it for many small scripts still, I feel that while it`s
not really dead, it`s also not really alive anymore... Let`s face it,
Tcl-support is dying out in general, sadly. But it is still by far my
favourite scripting-lanuage.

 So, I`m considering going standalone: Write my application as a
server-demon and only use a very small CGI or plugin to pass on requests to
it and receive the results.

 Advantage would be, that it`s independent of Rivet, allowing to use
NGinx or other HTTP-servers or even run it locally as a static
HTML-creator and Document-generator (can output several target formats from the
created document-tree). Also data/state-persistence is easier in a
standalone-server-application, compared to Rivet-modules, where I only have limited control over
when the application gets terminated/restarted depending on Apache-load and
other factors.

 Disadvantages: Handling of data access in httpd-context. E.g. if a
generated page refers to an image, I can handover the handling and delivery
of the image or other files to Apache/Rivet. A standalone-service needs
some clever mechanism to put file references into the HTML-output (or
other formats), that are then resolved by the httpd, including
access-rights-management, which is currently completely handled by Apache.

 Still, going standalone looks more tempting to me atm, because it
allows fine grained access control, different httpd-environments and local
application mode for other purposes. Any thoughts?

*Procs in namespaces vs. namespace ensembles:*
 Ensembles feel kind of elegant to me, but by default, I mostly
just write procs in namespaces, although related procs could go into an
ensemble - so much for clean APIs... But then I`m not sure about the name
resolving performance of ensemble commands vs. direct proc call. Just kind of
fuzzy thoughts about the pros and cons here. - Happy about useful
input...

 Thank you very much for reading, if you made it to this point...
Appreciate any helpful inputs and thought.

Best regards,
Stephan
--- 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