World: r3wp
[!Cheyenne] Discussions about the Cheyenne Web Server
older newer | first last |
Dockimbel 20-Jun-2009 [5154x2] | It's the burden of the developer to work hard to make life easier for users. ;-) |
Anyway, I'll try to list and add one or two comment lines for each available option in the next release, but I won't spend days writing docs for the config file. | |
Maxim 20-Jun-2009 [5156] | if the config GUI is web based... then it relies on the server actually working... but I'm not trying to argue with you, just pointing out the fact that server configuration is usually much better handled in text and I think many admins prefer it. the fact that everything in windows is GUI based is the most annoying aspect about it. |
Dockimbel 20-Jun-2009 [5157] | Well, I always thought that GUI was an improvement other text files. Cheyenne is suppose to work out of the box with a default config file. The admin web UI would be reacheable with http://server-ip/admin/ (just an example). |
Maxim 20-Jun-2009 [5158x2] | I have a generic configuration managing library... the documentation is directly embeded in the configuration engine... if you save out the config or print it on screen, you have all the docs right there with it. if you build a gui which uses the configuration data, you can also pull out the text from it. maybe that is what should be done.... allow string types within the config dialect (and store it appropriately). then you/we could easily build tools using that info directly. |
for myself... I would automatically turn off web-based config. if not only for security reasons. | |
Dockimbel 20-Jun-2009 [5160x2] | Embedding docs that can be extracted for a GUI is a good idea. |
I also have big concerns about security, such a remote admin app would be obviously strongly secured. | |
Maxim 20-Jun-2009 [5162] | this being said, I understand the appeal for GUI-based configs, but most power users are much more effective with raw data than having to fiddle with a screen hiding the data. |
Dockimbel 20-Jun-2009 [5163] | screen hiding the data you're already supposing that the admin GUI will be badly designed...I'm not talking about doing a Webmin clone (this is the typical example of *bad* UI design, IMHO). |
Maxim 20-Jun-2009 [5164] | Design is subjective in ALL cases. what is perfect for one context is insane in another. |
Dockimbel 20-Jun-2009 [5165] | True, but the goal is to make it simple and easy to use for the average user, without requiring to read lengthly docs. |
Maxim 20-Jun-2009 [5166] | as long as the config GUI is only a tool over the files, and it doesn't overwrite the files automatically, I won't complain :-) |
Dockimbel 20-Jun-2009 [5167] | Well, you'll have an option for turning it off, if you really prefer to type instead of clicking. ;-) |
Maxim 20-Jun-2009 [5168x2] | the format can become more stuctured too, if it makes it easier to load back in... but please don't loose the files themselves. |
hehe ;-) | |
Dockimbel 20-Jun-2009 [5170x2] | Both approaches can live together. I want the config file to keep the same current format even if overwritten by the UI. Most users won't even care about the config file anymore once the UI will be available. |
In fact, I even thought about making a lynx-compliant admin UI for text-only users. ;-) | |
Maxim 20-Jun-2009 [5172] | as a point of fact, it is very possible that some modules (like remark) will require stuff to be setup which is hard to simulate through a gui. managing a system of nested parameters and list is very complex to handle programatically. |
Dockimbel 20-Jun-2009 [5173] | Right, that's something Cheyenne's config file also doesn't handle (yet). |
Maxim 20-Jun-2009 [5174] | I'm adding words which are commands within remarks' module using the do variant of config definition... this allows me to grow a config by calling the same command multiple times.... this would be very unweildy to implement any other way (but not impossible)... maybe a function-based api could allow us to "hook" into the GUI but its pretty hard to cover all possibilities in any case... anhow... back to modulating remark. |
Dockimbel 20-Jun-2009 [5175x2] | There's a builtin "process" function in config DO blocks allowing to process nested blocks (see mod-static/if-loaded? definition). |
It's not as powerful as it could be, thought. | |
Maxim 20-Jun-2009 [5177] | ahh so that launches a new parse config on the block we give it? |
Dockimbel 20-Jun-2009 [5178] | Yep |
Maxim 20-Jun-2009 [5179] | when the config do is performed, I noticed you do a bind on the block... the thing I wonder is to what it is bound... its not obvious to me |
Dockimbel 20-Jun-2009 [5180] | It binds to the conf-parser object, because it needs (at least) to access the process function located in conf-parser. |
Maxim 20-Jun-2009 [5181] | k thx |
amacleod 20-Jun-2009 [5182] | Maxim, I tried with the port and it worked..thanks alot, but I could have sworn I had tried it like that too... |
Maxim 21-Jun-2009 [5183] | happy I was of help :-) |
Dockimbel 21-Jun-2009 [5184] | It should have worked even without the port number. It's a bug that will be fixed in next release. |
amacleod 2-Jul-2009 [5185] | Any reason why cheyenne does not allow a .r file to be read via http? It seemed to work with apache. I had to change it to a .txt file to get it to work..after batting my head for many minutes. |
Maxim 2-Jul-2009 [5186x2] | in the http.cfg file its assigned as a cgi script: bind-extern CGI to [.cgi .r] and the CGI handler will execute it. |
you can change this obviously. :-) | |
amacleod 2-Jul-2009 [5188] | Thanks. I thought it might have something to do with RSP but I see it is even simpler than that... |
Will 5-Jul-2009 [5189] | It would be nice to have Cheyenne support UTF8, I have it working here with some functions provided by Oldes, utf8/length? utf8/trim but a proper html entity converter is still missing, I think Gabriele has it but that's on hold by Reichart.. 8) |
Gabriele 5-Jul-2009 [5190] | of note, it's not "Reichart" that's holding it. it's just that Qtask the company has not decided on the license yet. |
Will 5-Jul-2009 [5191x2] | thanks for correcting me 8) |
btw, has Cheyenne been considered for Qtask? if not why? | |
Graham 5-Jul-2009 [5193] | because they use PHP I'm guessing |
Kaj 5-Jul-2009 [5194] | Cheyenne does PHP, but indeed, the Qtask frontends don't seem to use REBOL |
BrianH 5-Jul-2009 [5195x3] | Cheyenne has been considered within Qtask, and tested in a test project, with success. The lack of server-side SSL is a deal-breaker for the main site but it is usable for supplementary services. RSP went over well too, so Maarten is updating the original RSP for use in Qtask (though not with Cheyenne). |
because they use PHP I'm guessing - the promotional web site uses some PHP, but the main site is all REBOL. | |
the Qtask frontends don't seem to use REBOL - You are correct, the frontends use Javascript, generating the usual HTML and CSS. That Javascript is often generated using REBOL. Frontends in REBOL are possible though. | |
Dockimbel 5-Jul-2009 [5198] | Third party tools can be used to tunnel SSL, like stunnel or nginx. About RSP, does Cheyenne's RSP miss some features required by Qtask? |
BrianH 5-Jul-2009 [5199] | True about the tunneling tools, but I'm not the server guy so I don't know why they are still using Apache for the main site. I know they aren't married to it since the site isn't built on unique Apache modules, and because they mention looking at other servers. It wouuld depend on performance and scalability, so an alternate soltion would need to outperform and outscale Apache and FastCGI. As for the RSP features Maarten is adding, don't know what they are yet - it's on my todo list to compare the two RSPs to determine if there are features that the other could use. |
Dockimbel 5-Jul-2009 [5200] | Looks interesting, I hope you'll be able to publish here your conclusions. In theory, Apache+FastCGI should be faster than Cheyenne, but the application framework used in the FastCGI server, if not deeply optimized, might be a bottleneck. |
Will 5-Jul-2009 [5201] | btw, Dock, correct me if I'm wrong, it should be pretty easy to modify Cheyenne to distribute task-handlers (RSP processors) on computer nodes |
Dockimbel 6-Jul-2009 [5202] | Well, there's just a local dependency on config file to remove first (in my todo list) to allow remote worker process (for RSP, CGI,...). But you need a also a remote process manager to handle the launching of worker processes. Anyway, I think that using a front load balancer (supporting session affinity) with several servers is a simple and efficient solution. |
ChristianE 18-Jul-2009 [5203] | What are the requirements to get a connection to a mysql database? I have a %httpd.cfg as below --------------------------httpd.cfg -------------------------------- globals [ ... worker-libs [ ... %path/to/mysql-driver/mysql-protocol.r ... ] ... ] my.virtual.host [ .... databases [ db-name mysql://root:[lpass-:-127-:-0-:-0-:-1]/table] .... ] ---------------------------------------------------------------------- As far as I can see from the documentation and sample files, I should now be able to use SEND-SQL a alike on DB-NAME, but that gives nothing but script errors ** Script Error : db-name has no value ** Where: rsp-script ** Near: [print mold db-name I've already spent hours on this without getting a clue on what to do. |
older newer | first last |