search

HBPVIS / ZeroEQ

Cross-platform C++ library for fast binary and REST messaging
https://hbpvis.github.io/
Other
41 stars 25 forks source link

http server index spec #171

Closed eile closed 8 years ago

eile commented 8 years ago

Pretty version: https://github.com/eile/ZeroEQ/blob/master/doc/feature/index.md

rdumusc commented 8 years ago

This is a reasonable default for most use cases, and it's clear and simple to use. I think it can be implemented as is, without conflicting with the following remarks:

We may not want to limit the feature to the case of a static index page. With the current situation, dynamic pages can also be provided (for any arbitrary url) with just a minor variation of the StaticContent class in Tide. However, the semantics are ugly and users have to "hack" servus::Serializable::toJson() to achieve this result. Maybe zeroeq could provide some base class to make things more clean: class HtmlPage { virtual std::string getHtml() const = 0; }; with class Server { void register( const HtmlPage& page, const std::string& url ); };

eile commented 8 years ago

+1 on the HtmlPage.

Not sure about the generalization to URLs - it feels like feature creep towards making http::Server like apache & co. Opinions?

rdumusc commented 8 years ago

+1 for your change. I agree that we should code only what is required and nothing more. We can start with (static) homepage as you suggest.

As for the general question, there is a risk of feature creep, but I am afraid that these extra developments will be needed at some point. For instance, Tide could benefit from a more advanced web UI. It would complement the touch interface and replace the complicated master application & VNC setup. This implies delivering images and javascript in addition to html. In the absence of a proper API, this will happen through more "hacking" of StaticContent : public servus::Serializable. or switching to a different network library.

eile commented 8 years ago

@rdumusc Thanks, noted as issue in spec.