Re: [librsync-devel] Re: state of the rsync nation?(revisited 6/2003 from 11/2000)

[Donovan Baarda]

On Mon, 2003-08-04 at 11:05, Martin Langhoff wrote:
> Donovan Baarda wrote:
> 
> > For the record, librsync version 0.9.6 is _almost_ ready in CVS. A bug
> >
> >has been detected but not isolated yet for large files (2G+). If it's
> >not squashed soon I'm tempted to release anyway with a KNOWN_BUGS that
> >reports this.

Last night I found and squashed a bug that caused the problem. I'm
waiting on feedback from the user that reported it to confirm it is now
fixed.

> Donovan,
> 
> I am just looking around for hints on compiling librsync under cygwin 
> (gcc), and happened to find this post of your promising 0.9.6, which 
> runs under cygwin... 
> 

I know that post was ages ago, but due to work commitments I never got a
chance to release it. Every time I got a small chance to look at it
again, I kept finding little niggly things that really should have been
fixed before release.

The CVS is only intermittently updated, so I only bother tagging on
release, which still hasn't happened yet. The CVS HEAD is the current
release candidate. I don't commit unless it passes a "make distcheck" so
it should never be broken. 

> Are the sources at least tagged, so I can get the mfrom CVS? What tags?

Your timing is impeccable. Just last night I finalised the MSVC updates
and fixed the last known bug. That means there is nothing outstanding
for the release... this should be 0.9.6, but I'm giving it a day or so
to get feedback before I tag and release.

There is a delay on SF between developer and anon CVS, so it is possible
the final checkins are not yet visible. In the meantime, there is a
tarball available at;

http://minkirri.apana.org.au/~abo/projects/librsync/librsync-0.9.6.tar.gz

This compiles and builds on win32 using cygwin and/or MSVC.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: [librsync-devel] Re: state of the rsync nation?(revisited 6/2003 from 11/2000)

[Martin Langhoff]

Donovan Baarda wrote:

For the record, librsync version 0.9.6 is _almost_ ready in CVS. A bug

has been detected but not isolated yet for large files (2G+). If it's
not squashed soon I'm tempted to release anyway with a KNOWN_BUGS that
reports this.
 

Donovan,

I am just looking around for hints on compiling librsync under cygwin 
(gcc), and happened to find this post of your promising 0.9.6, which 
runs under cygwin... 


Are the sources at least tagged, so I can get the mfrom CVS? What tags?

thanks!





martin





--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Donovan Baarda]

On Tue, 2003-06-10 at 14:25, Martin Pool wrote:
> On  8 Jun 2003, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> 
> > The "next big thing" in delta calculation is probably going to be the
> > vcdiff encoding format, which should allow a common delta format for
> > various applications and supports "self-referencing delta's", which
> > makes it capable of compression. According to the xdelta project this
> > has already been implemented, and I'm keen to see Josh's code, as it
> > could be used as the basis for a cleanup/replacement of at least the
> > "patch" component of librsync.
> 
> Do you have a link for this?  Josh plays his cards pretty close to his
> chest.  The XDelta page seems to be even more inactive than librsync
> :-/

yeah, the xdelta page on SourceForge has a few announcements about
vcdiff support that are fairly recent, but everything else hasn't been
touched for ages. It looks like Josh is only using SF as a static
front-page where he posts announcements and all the real work is
happening somewhere else...

Unfortunately I don't know where that somewhere else is... hence my
eagerness to actually see the code.

The vcdiff standard is available as RFC3284, and Josh is listed as one
of the authors. 

I also had some correspondence with Josh ages ago where he talked about
how self-referencing delta's can directly do compression of the miss
data without using things like zlib and by default gives you the
benefits of rsync's "context compression" without the overheads (rsync
runs a decompressor _and_ a compressor on the receiving end just to
regenerate the compressed "hit" context data).


-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[jw schultz]

On Tue, Jun 10, 2003 at 06:13:48PM +1000, Brad Hards wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, 10 Jun 2003 14:21 pm, Martin Pool wrote:
> > I guess the reason why you're interested in doing it is so that you
> > can browse public rsync mirrors from Konqueror/whatever?
> Yep. Also, I was playing with the idea of rsync with Service Location Protocol 
> to use as a replacement for the crappy practice of sharing data over floppy 
> disks. The rough concept was that each machine had a shared directory, which 
> you could conveiently label and advertise over SLP. 
> 
> > Speaking only for myself, I don't think this is worth spending time
> > on.  It would be hard to write a wire-compatible library, and hard to
> > refactor rsync into such a library.
> I considered it, but not very long :)
> 
> > Not only might a new tool be written more easily without baggage, it
> > might also (in a couple of years) persuade people running mirror sites
> > to switch.  I know many of them are unhappy with rsync at the moment:
> >
> >  - large memory usage
> >  - no really good ways to restrict client usage
> >  - ...
> Go superlifter! For what it is worth, the things I identified during the 
> abortive kioslave / SLPv2 share development:
> 1. More secure than FTP.
> 2. Easy to label shares/directories and provide fine grained access control, 
> if desired.
> 3. Client side library that doesn't require hellish text parsing, or at least 
> hides it from you.
> 4. Well delimited packets, so you can tell when one has been dropped.

hmm, i can hear the gears
meshing and turning between my ears :)

Current rsync just doesn't fit well as a lightweight network
service.  The current protocol is too tightly coupled to
monolithic commands to support in a browsing and
interactivity in a reasonable manner.

What would really be useful for that would be quite
different that the current rsync.  And i think, different
that the direction we have discussed regarding rsync
replacements.  However, i think it may be worth exploring.
Let me put out a brief description and if you all want to
discuss it further we can start a new thread.

 -

Service utility would be much smaller than the client
utility.  The service utility could be started in an ssh
shell initiated by the client.  The daemon would be a
completely different executable because it would add
configfiles, authentication and encryption.  This means that
the client, service and daemon would be separate executables.

I'm only going to describe the core functionality of the
service util and daemon from the protocol perspective.
These are the commands the service would support defined in
server relative terms.  Most of these would operate on a CWD
relative filename or perhaps on a numeric file_id (probably
also CWD dependant).

set
unset
show
set assorted options (numeric IDs etc.)

cd
change directory.

stat
send the stat(2) info for a single file or directory
This could optionally include a file checksum.

ls
list files within specified directory.  Optionally
with stat info for each.  This is not recursive.

sum
send file checksum.

blocksum
send block checsums for file.

delete  
delete a file or directory.  This is recursive.

create
create a new file with given name containing
attached data and set the perms to those attached.

set_perms
set ownership and permissions of file in accordance
with settings and process permissions.

get_uids
get_gids
get_users
get_groups
return the user/group IDs corresponding to the list
of names, or user/group names corresponding to the
list of IDs.

get
send the contents from a file for each offset and length
specified in this command.

update
update a file.  This would be accompanied by a
sequence of offset+length of existing file contents
and new file contents to be merged to form new file.

No doubt there are a few more commands that would be needed
as well as protocol and capability negotiations.

A major factor here is that the server would be extremely
lightweight.  The load of generating the change list and
comparing block checksums with rolling to calculate the
update sequence would all be born by the client.  Further,
to the degree possible it would favour a client on the
downstream side of an asymmetric network connection.

The protocol while not stateless would be a set of atomic
commands so if the client lost its server connection it
could reestablish the session cheaply and pick up where it
left off.

For performance the communications would have to be
pipelined and run full-duplex to keep data flowing as fast
as possible.  This only impacts the client.  Little issuing
of a command and waiting for results.  Mostly issue commands
as fast the client can generate them and process the results
as they come in.

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Brad Hards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 10 Jun 2003 21:02 pm, Stefan Nehlsen wrote:
> Some time ago I found a patched rsync with slp-support. I think it
> was on the openslp site and was a demonstration for the use of slp.
>
> As server it announced its modules to an slp-server and as client it
> asked for location of servers and modules.
That sounds familiar :->
http://zeroconf.sourceforge.net/?selected=demo

There wasn't much reaction when I announced it. Generally it was considered to 
be a cool hack, but not of any real usage.

Brad
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+5bydW6pHgIdAuOMRAkQeAKC0tfwl6q5MmEgA4Xa4wSoeQKLFpwCgoBoi
qGEe+/VRywCysXZ42oKThP0=
=fPgE
-END PGP SIGNATURE-
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Stefan Nehlsen]

On Tue, Jun 10, 2003 at 06:13:48PM +1000, Brad Hards wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, 10 Jun 2003 14:21 pm, Martin Pool wrote:
> > I guess the reason why you're interested in doing it is so that you
> > can browse public rsync mirrors from Konqueror/whatever?
> Yep. Also, I was playing with the idea of rsync with Service Location Protocol 
> to use as a replacement for the crappy practice of sharing data over floppy 
> disks. The rough concept was that each machine had a shared directory, which 
> you could conveiently label and advertise over SLP. 

Some time ago I found a patched rsync with slp-support. I think it
was on the openslp site and was a demonstration for the use of slp.

As server it announced its modules to an slp-server and as client it
asked for location of servers and modules.

It was just ment as a demo but it seemed to be usable.


cu, Stefan
-- 
Stefan Nehlsen | ParlaNet Administration | [EMAIL PROTECTED] | +49 431 988-1260
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Brad Hards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 10 Jun 2003 14:21 pm, Martin Pool wrote:
> I guess the reason why you're interested in doing it is so that you
> can browse public rsync mirrors from Konqueror/whatever?
Yep. Also, I was playing with the idea of rsync with Service Location Protocol 
to use as a replacement for the crappy practice of sharing data over floppy 
disks. The rough concept was that each machine had a shared directory, which 
you could conveiently label and advertise over SLP. 

> Speaking only for myself, I don't think this is worth spending time
> on.  It would be hard to write a wire-compatible library, and hard to
> refactor rsync into such a library.
I considered it, but not very long :)

> Not only might a new tool be written more easily without baggage, it
> might also (in a couple of years) persuade people running mirror sites
> to switch.  I know many of them are unhappy with rsync at the moment:
>
>  - large memory usage
>  - no really good ways to restrict client usage
>  - ...
Go superlifter! For what it is worth, the things I identified during the 
abortive kioslave / SLPv2 share development:
1. More secure than FTP.
2. Easy to label shares/directories and provide fine grained access control, 
if desired.
3. Client side library that doesn't require hellish text parsing, or at least 
hides it from you.
4. Well delimited packets, so you can tell when one has been dropped.

Brad
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+5ZM9W6pHgIdAuOMRAuN4AKCYGFmbPEBbj0cL4mDVgFTMmrcsqQCgi1Ru
K/zTNJbUmAxZ/mW1UqdqVoA=
=FZZG
-END PGP SIGNATURE-
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Martin Pool]

On  8 Jun 2003, Donovan Baarda <[EMAIL PROTECTED]> wrote:

> The "next big thing" in delta calculation is probably going to be the
> vcdiff encoding format, which should allow a common delta format for
> various applications and supports "self-referencing delta's", which
> makes it capable of compression. According to the xdelta project this
> has already been implemented, and I'm keen to see Josh's code, as it
> could be used as the basis for a cleanup/replacement of at least the
> "patch" component of librsync.

Do you have a link for this?  Josh plays his cards pretty close to his
chest.  The XDelta page seems to be even more inactive than librsync
:-/

-- 
Martin 
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Martin Pool]

On  9 Jun 2003, Brad Hards <[EMAIL PROTECTED]> wrote:
> Hash: SHA1
> 
> On Sun, 8 Jun 2003 15:43 pm, Donovan Baarda wrote:
> > The comments about rsync never using libhsync/librsync are still true
> > for the foreseeable future. There are many things rsync includes that
> > are still missing from librsync, and the rsync implementation is very
> > tightly coupled, with many backwards compatibility issues. Even when
> > librsync reaches the point of being as good or better than rsync at
> > signature/delta/patch calculation, it would be a major task to "fit it
> > into" rsync.

> The downside to not having a library that is wire-compatible with rsync 
> - --daemon is that it is damn difficult to write something that works as a VFS 
> / kioslave type device. I had a hack at this, by wrapping the rsync 
> executable, and it worked a bit, but it was way too fragile for any real use:
> http://www.cuneata.net/rsync-kio.html

I guess the reason why you're interested in doing it is so that you
can browse public rsync mirrors from Konqueror/whatever?

Speaking only for myself, I don't think this is worth spending time
on.  It would be hard to write a wire-compatible library, and hard to
refactor rsync into such a library.

Not only might a new tool be written more easily without baggage, it
might also (in a couple of years) persuade people running mirror sites
to switch.  I know many of them are unhappy with rsync at the moment:

 - large memory usage
 - no really good ways to restrict client usage
 - ...

-- 
Martin 
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Brad Hards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sun, 8 Jun 2003 15:43 pm, Donovan Baarda wrote:
> The comments about rsync never using libhsync/librsync are still true
> for the foreseeable future. There are many things rsync includes that
> are still missing from librsync, and the rsync implementation is very
> tightly coupled, with many backwards compatibility issues. Even when
> librsync reaches the point of being as good or better than rsync at
> signature/delta/patch calculation, it would be a major task to "fit it
> into" rsync.
The downside to not having a library that is wire-compatible with rsync 
- --daemon is that it is damn difficult to write something that works as a VFS 
/ kioslave type device. I had a hack at this, by wrapping the rsync 
executable, and it worked a bit, but it was way too fragile for any real use:
http://www.cuneata.net/rsync-kio.html

Brad
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+5Hw9W6pHgIdAuOMRAr7xAJ4j8mRta8NziilLSc39hguut+8guQCeIJ5R
+wZ/EDtAfZm4baxESxzBcIE=
=HhLE
-END PGP SIGNATURE-
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: state of the rsync nation? (revisited 6/2003 from 11/2000)

[Donovan Baarda]

On Sun, 2003-06-08 at 00:31, Jeff Kowalczyk wrote:
> I'm interested in these very questions (librsync-rsync relationship,
> remaining limitations of rsync, active prospects for ground-up rewrites),
> Google searches for rsync info have proved a little too vague due to the
> programs ubiquity. Much has certainly changed since this was written,
> could some people with knowledge in these areas could update martin's
> response for the state of rsync, June 2003? Thanks.

regarding librsync... It is still in sort-of-active development on
SourceForge by a variety of developers... a new release is waiting in
CVS for me to finally get around to releasing it, but I'm busy on a big
contract at the moment so its currently on hold pending some more
cygwin/win32 testing. It is in active use by projects like rdiff-backup.

AFAIK, rproxy is pretty much dead, and the only version that exists
depends on a very old version of libhsync. The closest thing to this
available now is the http proxy "proof of concept" with xdelta, but it's
radically different in many ways to the old rproxy (due to xdelta not
using signatures).

> On 13 Nov 2000, Jason Ozolins wrote:
> http://lists.samba.org/pipermail/rsync/2000-November/003147.html
> > Just a quick question: is the librsync contained within the rproxy
> > source code meant to be tracking the development of the mainstream
> > rsync, or is it a stripped-down thing meant only to support rproxy?
> 
> On 13 Nov 2000, Martin Pool Responded: Here's a quick history:
[...]
> rsync gave rise to Josh Macdonald's XDelta, which is optimized for the
> case where old and new versions are on the same machine, and so it can
> generate more efficient deltas.

xdelta is still under active development by Josh, and is evolving into a
fancy versioning virtual file system... an ideal back-end for something
like subversion. Josh tends to develop stuff with little fanfare, but
his code tends to be _very_ clean.

> tridge extracted the algorithm into librsync, which I renamed to libhsync
> when I changed the wire format.  The code currently checked in as librsync
> is in my opinion not very good.  It tries to make the algorithm available
> at various levels to programs that would like to use it, though the only
> user at the moment is rproxy.  rsync doesn't use libhsync -- possibly it
> never will, as we care enough about rsync performance that tighter
> integration is justified.  Well, if we were starting from scratch it might
> be separated out, but it's not worth doing it retrospectively now.
[...]

This is largely still true, except libhsync changed back to librsync and
now has its own project on SourceForge separate from the mostly defunct
rproxy. librsync itself has no "wire format", being just a general
purpose signature/delta/patch library implementing the rsync algorithm.

The comments about rsync never using libhsync/librsync are still true
for the foreseeable future. There are many things rsync includes that
are still missing from librsync, and the rsync implementation is very
tightly coupled, with many backwards compatibility issues. Even when
librsync reaches the point of being as good or better than rsync at
signature/delta/patch calculation, it would be a major task to "fit it
into" rsync.

rsync also has more active development, mostly in the form of
incremental feature additions and the resulting "bugfix fire-fighting",
all of which lead to an even more tangled implementation. Occasionally
there are efforts to re-write and clean up sections of the code, but
they are (rightly) regarded cautiously because of the breakage risk
involved for little immediate gain.

The librsync code in CVS is still largely "not very good". It is pretty 
messy and needs a good cleanup. The API is mostly OK though, and it
_does_ work quite well, with no known bugs. I have some plans for a
major cleanup and optimisation of the code based on my experiences with
pysync. I have a patch submitted that I plan to commit after the next
release that optimises and cleans up the delta calculation code quite a
bit.

The "next big thing" in delta calculation is probably going to be the
vcdiff encoding format, which should allow a common delta format for
various applications and supports "self-referencing delta's", which
makes it capable of compression. According to the xdelta project this
has already been implemented, and I'm keen to see Josh's code, as it
could be used as the basis for a cleanup/replacement of at least the
"patch" component of librsync.

Possibly worth also mentioning is things like pysync which is a
demonstration implementation of rsync and xdelta, as well as a wrapper
for librsync. I'm kind of embarrassed though that at the moment
rdiff-backup probably has a better python wrapper of librsync than
pysync does.

I believe there has also been some implementations of rsync in Perl (one
that claims to talk to rsync, which is an amazing achievement), but I'm
not up to date on those. I think someone has a Perl wr

state of the rsync nation? (revisited 6/2003 from 11/2000)

[Jeff Kowalczyk]

I'm interested in these very questions (librsync-rsync relationship,
remaining limitations of rsync, active prospects for ground-up rewrites),
Google searches for rsync info have proved a little too vague due to the
programs ubiquity. Much has certainly changed since this was written,
could some people with knowledge in these areas could update martin's
response for the state of rsync, June 2003? Thanks.

On 13 Nov 2000, Jason Ozolins wrote:
http://lists.samba.org/pipermail/rsync/2000-November/003147.html
> Just a quick question: is the librsync contained within the rproxy
> source code meant to be tracking the development of the mainstream
> rsync, or is it a stripped-down thing meant only to support rproxy?

On 13 Nov 2000, Martin Pool Responded: Here's a quick history:

In the beginning was rsync, which is a file transfer protocol. At the
moment I look after the day-to-day stuff, and tridge watches the
evolution.

rsync gave rise to Josh Macdonald's XDelta, which is optimized for the
case where old and new versions are on the same machine, and so it can
generate more efficient deltas.

tridge extracted the algorithm into librsync, which I renamed to libhsync
when I changed the wire format.  The code currently checked in as librsync
is in my opinion not very good.  It tries to make the algorithm available
at various levels to programs that would like to use it, though the only
user at the moment is rproxy.  rsync doesn't use libhsync -- possibly it
never will, as we care enough about rsync performance that tighter
integration is justified.  Well, if we were starting from scratch it might
be separated out, but it's not worth doing it retrospectively now.

The problems with rsync at the moment are basically:

 * Quirks of design ('triangular' TCP sockets, etc) tend to provoke
   bugs in operating systems or remote shells.

 * Useful features have been added in ad-hoc, and so the code is
   fairly crufty in places.

 * People still want even more features for special cases.  To avoid
   feature hell, my opinion is that we need a clean scripting or plugin
   mechanism.=20

 * rsync is optimized for transferring relatively small trees
   (e.g. the rsync source tree) across slow links (e.g. 56kbps ppp). This
   is fine and important, but people want to use it for different
   situations (10GB, 100Mbps, 50 in parallel) where some design decisions
   (e.g. traverse the whole tree up front) are no longer optimal or even
   adequate.

rproxy uses the rsync algorithm to improve HTTP caching -- it's not
rsync-over-HTTP.  I'm the lead developer for it, and it's in beta.

Completely unrelated to rproxy, sfr has added a small feature to tunnel
rsync through HTTP CONNECT proxies.

Therefore, some people at Linuxcare (primarily rusty, tridge and myself)
are looking at a ground-up rewrite with new code and a new network
protocol.  (Of course we will have a fallback mode.)  This might be called
rsync-3.0, or rsync-tng, or tsync, or something else.

This will likely be a more traditional client-server protocol, somewhat
similar to FTP and HTTP in that the client sends commands to the server to
put or get files.  However, commands will be pipelined,
network-independent binary, and using only a single tcp connection. In
general we hope that there will be less special cases, and probably that
there will be less application-level intelligence in the server and more
in the client.  This should be a firmer foundation for building things
such as

 * implementations in different languages/platforms (Java, Win32
   native, INTERCAL, ...)

 * interactive rsync (like ftp(1))

 * two-way rsync (controlled by the client, which could be automatic
   or even have a GUI.)

 * rsync as a transport for things such as CVS

Discussion about either feature requests or implementation ideas would be
very welcome.  It's probably best to send them to the rsync mailing list.

> The reason I ask is that I am thinking of extending Bob Edwards'
> rsync-based backup server architecture here at DCS, using a database to
> hold file metadata, doing binary deltas for history, and doing block
> compression on backed up data.  This is a fair amount of stuff to
> change, and I was wondering which source base would be better to start
> with.

You might like to look at the XDelta work on XDFS and PCVS, or in the
longer term to work on rsync 3.0.

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html