| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HTML forms now use a custom CSS instead of importing Bootstrap 4. This new
CSS is basd on Bootstrap 5 with some minimal differences to make it look a bit
like the older theme.
Bootstrap was removed because these pages don't need its full power and also
because it was difficult for some text editors to handle the one-long-line
minified CSS embedded in the HTML. Since the forms are just a series of label
+ input elements, using a specific set of directives doesn't add any
significant maintenance cost while making editing easiers.
A new form to generate a simplified card was added. This card is desgined to
reduce the leftover whitespace when some optional entries are left blank in
the "full" form, while at the same time giving importance to the QR code
containing the GNS address. Its layout can be improved.
The simplified form can also be used to generate a PNG picture of the QR code,
so that it can be included in other graphical media other than a business
card, for example on a flyer or in the signature of a HTML-based e-mail.
Generally, the gnunet-bcd service should provide a slightly better user
experience, even if it's just to provide different pages for different errors
but with a unified style.
The logo used in the cards has been changed from the previous "gnu in front of
a spiderweb" illustration to the new "gnu-shaped network of peers" image. It
is also now a pure TikZ picture instead of being made using PSTricks, because,
apparently, there is an incompatibility between the two packages in recent
versions which made it impossible to compile the file.
As a consequence of the incompatibility between TikZ and PSTricks, the QR code
is now generated using the 'qrcode' package.
This commit contains some changes to FCFS, but they're just some minor fixes
and are unrelated to the changes to BCD.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivations behind these changes are as following.
To begin with, at the most superficial level, the form is given a better
appearance, instead of some plain XHTML. Additionally, the served pages can
be substituted with something else by using an entry in the configuration
value, altough with some limitations.
The page listing all the registered zones has been removed in favour of a
search function. A configuration entry could've been used to let service
operators choose between showing the full listing or not, but at the same
time, being presented with a (possibly) giant list of names is not that great
from a usability point of view. Having a search function is, at the very
least, faster than having to wait for the full list to be displayed before
being able to use the user agent's page search feature.
Other than the above, people registering names with the service might not want
to be known by everyone. Even though checking if a certain name or key was
registered already can be known simply by querying the service, it's not
straightforward to associate a name with a specific key (or viceversa).
Last but not least, the service was restructured to be more "route-oriented"
instead of the traditional (X)HTML document format. The main purpose of this
change is to decouple usage of the service from the tools used to access it.
With a traditional document, users are pretty much forced to use a web
browsers as data submission is carried through the standard HTML form
handling. Now, it is possible to access the service using any tool capable of
speaking HTTP, regardless of wether it's a web browser, cURL or even a custom
tool specific for this service.
Another advantage of this approach is that it allows adding "layers" to the
service, for example an authentication check before letting users register a
name. As long as the layer immediately on top of the service is able to send
some JSON using HTTP, there is no need to have users access the service
itself: just put a "proxy" inbetween and run the service locally, while the
proxy handles other administrative tasks before a name can be registered.
By using layers, the service can keep being small feature-wise (i.e. provide
only searching and registering), while everything else is provided by other
applications, including access through protocols other than HTTP.
|
| |
|
| |
|
|
|
|
| |
With some other changes to sentences here and there as I found appropriate.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PostgreSQL since version 12 no longer supports 'WITH OIDS':
Previously, a normally-invisible oid column could be specified during
table creation using WITH OIDS; that ability has been removed. Columns
can still be explicitly declared as type oid. Operations on tables that
have columns created using WITH OIDS will need adjustment.
The system catalogs that previously had hidden oid columns now have
ordinary oid columns. Hence, SELECT * will now output those columns,
whereas previously they would be displayed only if selected explicitly.
Drop 'WITH OIDS' as it was stated even on tables for plugins which
didn't make any use of the then exposed 'oid' column.
In the case of datacache and datastore the 'oid' column is used,
so replace the 'WITH OIDS' statement with an explicit 'oid' column
having 'OID' type and a corresponding sequence.
No measures are taken to still work with PostgreSQL before version 12.
Users should update PostgreSQL to version 12 or newer.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
|
|
|
|
| |
#6475.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
work
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|