Closed ansiwen closed 6 years ago
Seems like the right thing to do here is take an explicit time source in either the webmachine functor, or the dispatch function. Either way, this time source would have something like the following type:
type time_source : unit -> int
For Unix, this could just be gettimeofday or something similar. For Async or Lwt, this would read some state somewhere that was asynchronously updated by a timer.
This seems like a nice self-contained contribution. If you're interested in writing it I would review and merge. Give me a heads up on which approach you're thinking of beforehand, though.
I'm happy to help, but I'm pretty much an Ocaml-Novice still, so I can't really see now, which of the two approaches would be better. Maybe the more simple one? ;-) If you assist by leading me through that, I can certainly try. First question would be: shouldn't be there already a time source somewhere? I can't imagine such a basic thing is missing yet.
ping. would be nice if someone can fix this
I'm happy to execute it with a small amount of direction and/or someone available to ask, in order to make it time efficient. (Don't have too much time to waste, as probably everybody, so I would not like to research for hours on the internet if problems arise.)
Yesterday I found out I can't upgrade to mirage 3.0.5, because it comes with implicit dependencies on cohttp higher than 0.20.2. So, our interest to solve that is even higher now. I could reserve like 3-5 hours a week on that. I would just ask for assistance, to keep it efficient. So, for some tutoring from one of you guys, you will get this! :smiley_cat:
I can see two paths forward:
Calendar
are used in here, and maybe they are few enough to be reimplemented here or in a standalone library without unixcalendar
depend on Unix and why (I'd suspect some call to gettime
).I investigated this for a demo I put together involving webmachine
and Mirage in March, and hacked out the bits requiring calendar
at https://github.com/yomimono/ocaml-webmachine/commit/33f825de31f18f13d3d8f2fe558a0950f558e392 (forgive the OASIS crud, the interesting bits are at line 701 of lib/webmachine.ml
and below in that view).
@tmcgilchrist I don't think removing the functionality entirely is a good idea and I'll be very surprised if the maintainer accepts a patch that does so; I intended only to point at answers to @hannesm's first question above.
Agreed it's probably not a good idea (just a quick hack on the train). I wanted to make the changes available if people wanted to use a branch against current master.
Building the date parser and working out how to pass in a time source will take me longer. Might get time this week to have a go at it.
@seliopou BTW: How about splitting the functionality into webmachine and webmachine-unix? Or is the unix-dependent part essential?
Handling caching headers requires a time source, and parsing the headers (currently) requires calendarlib. So unfortunately it's gotta be functorized, or at the very least somehow parameterized.
We are using
webmachine
in amirage
unikernel, and version 0.4.0 contains a dependency oncalendar
which breaks xen builds:Installed package versions are: