You mention a couple of concepts: "persistence" and "caching" that I think
are orthogonal to the systemd -- at least in owfs's view of them.
1. Caching is the storing of 1-wire slave readings (in owserver) for a
short while to work around the relatively slow 1-wire bus speeds. It should
always be correct to refer back the the primary source -- the actual 1-wire
sensor. If systemd needs to restart an owserver, or wait until the server
is on line, the eventual data read would still be fresh.
2. The persistence we use is to reuse tcp connections to owserver, saving
the cost of the full tcp handshake. Clearly with an interruption in service
and restarting owserver, the tcp connection would be recreated. The design
is to fall back gracefully to non-persistent tcp connections if the
persistent connections are lost, timed out, or too many.
ownet is a client that talks to owserver, exclusively (it can't talk
directly to the 1-wire bus). All the caching would be on the owserver side.
If the ownet client handles data by saving it to disk, that should be
independent of systemd and owserver configuration.
On Thu, Jun 12, 2014 at 11:42 AM, Vajk Fekete <vaj...@gmail.com> wrote:
> Hi,
>
> How will this handle the persistent features? As I understand ownet does
> cache values for example. If the listener is handled externally and ownet
> is not running generally, would it have to use disk as persistence?
>
> Vajk
>
>
> On Thu, Jun 12, 2014 at 1:50 PM, Jan Kandziora <j...@gmx.de> wrote:
>
>> Am 12.06.2014 12:38, schrieb Paul Alfille:
>> > So can we have the situation where owserver waits for both
>> >
>> > 1. the USB device (say) to be available
>> > 2. a request to come in
>> >
>> > and appear always available to the clients?
>> >
>> As systemd handles the socket connection (and process start) alone, I
>> think the only way to handle this both gracefully and not cluttering the
>> systemd configuration with awkward workarounds is to support that
>> situation that there is no host adaptor available when owserver is
>> started.
>>
>> Kind regards
>>
>> Jan
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
