chore: reformat for better visibility
This commit is contained in:
509
VISION.md
509
VISION.md
@@ -1,312 +1,377 @@
|
|||||||
# blogging Desktop Server
|
# blogging Desktop Server
|
||||||
|
|
||||||
Back in the day I had a tool named Python Desktop Server that was a self-contained blogging engine with
|
Back in the day I had a tool named Python Desktop Server that was a
|
||||||
an integrated webserver and database that allowed management of blog posts in an easy local way and a
|
self-contained blogging engine with an integrated webserver and database that
|
||||||
sync to a cloud system for syncing data and also rendering the full blog.
|
allowed management of blog posts in an easy local way and a sync to a cloud
|
||||||
|
system for syncing data and also rendering the full blog.
|
||||||
|
|
||||||
## Main Vision
|
## Main Vision
|
||||||
|
|
||||||
create a electron app in this folder that uses typescript for all the logic code and sqlite and a proper
|
create a electron app in this folder that uses typescript for all the logic code
|
||||||
database framework around it for local storage of data. The UI should be aligned with the UI patterns
|
and sqlite and a proper database framework around it for local storage of data.
|
||||||
used by vscode. The name of the application is "blogging Desktop Server" and the shortname is bDS. Startwith
|
The UI should be aligned with the UI patterns used by vscode. The name of the
|
||||||
default layout for edit and view menues and things like that. I don't want the app to use raw SQL, I want some
|
application is "blogging Desktop Server" and the shortname is bDS. Startwith
|
||||||
proper layer between those and proper wiring where all actual functional code is kept in engine classes and the
|
default layout for edit and view menues and things like that. I don't want the
|
||||||
UI realy just does presentation and reacts to state changes properly, so that long-running processes can
|
app to use raw SQL, I want some proper layer between those and proper wiring
|
||||||
properly integrate as async tasks.
|
where all actual functional code is kept in engine classes and the UI realy
|
||||||
|
just does presentation and reacts to state changes properly, so that
|
||||||
|
long-running processes can properly integrate as async tasks.
|
||||||
|
|
||||||
The main area of the window must be a tabbled view, where multiple tabs can be open at the same time and are
|
The main area of the window must be a tabbled view, where multiple tabs can be
|
||||||
retained over program runs. The tabs can be different tabs like media file tabs, post tabs for multiple
|
open at the same time and are retained over program runs. The tabs can be
|
||||||
posts and setting tabs or whatever will come later.
|
different tabs like media file tabs, post tabs for multiple posts and setting
|
||||||
|
tabs or whatever will come later.
|
||||||
|
|
||||||
Blog post metadata should be managed in the SQLite database in the user local folder, so it persists
|
Blog post metadata should be managed in the SQLite database in the user local
|
||||||
application runs properly. for blog posts, create a subfolder /posts/ there where each post is stored as a
|
folder, so it persists application runs properly. for blog posts, create a
|
||||||
markdown file with a properties segment in the top of the file with YAML like property definitions, so all
|
subfolder /posts/ there where each post is stored as a markdown file with a
|
||||||
metadata can always be reconstructed from posts. Do the same with images, keeping them in /media/ under the
|
properties segment in the top of the file with YAML like property definitions,
|
||||||
user local path, in that case storing the image file sand for each image file a properties sidecar file that
|
so all metadata can always be reconstructed from posts. Do the same with images,
|
||||||
uses the same header structure as for posts.
|
keeping them in /media/ under the user local path, in that case storing the
|
||||||
|
image file sand for each image file a properties sidecar file that uses the same
|
||||||
|
header structure as for posts.
|
||||||
|
|
||||||
The application must be offline-first, everything must work in airplane mode (except exporting / AI of course).
|
The application must be offline-first, everything must work in airplane mode
|
||||||
It must be fully self-contained during editing and previewing and managing content. Every internal structure
|
(except exporting / AI of course). It must be fully self-contained during
|
||||||
must have reflections in the filesystem, so available tags, available categories, all those things must be
|
editing and previewing and managing content. Every internal structure must have
|
||||||
automatically reflected to the filesystem in a per-project way. Use a meta/ folder under the project folder
|
reflections in the filesystem, so available tags, available categories, all
|
||||||
for those files.
|
those things must be automatically reflected to the filesystem in a per-project
|
||||||
|
way. Use a meta/ folder under the project folder for those files.
|
||||||
|
|
||||||
There should be good cloud-storage based syncing that can be triggered when online again and should use
|
There should be good cloud-storage based syncing that can be triggered when
|
||||||
asynchronous syncing with auto-resolving of issues. The solution should be end-user friendly and not
|
online again and should use asynchronous syncing with auto-resolving of issues.
|
||||||
too technical in setup.
|
The solution should be end-user friendly and not too technical in setup.
|
||||||
|
|
||||||
The application must be able to support multiple projects (ie web sites), so there must be a way to create
|
The application must be able to support multiple projects (ie web sites), so
|
||||||
new projects and select current project. The UI is only showing all data of the current selected project and
|
there must be a way to create new projects and select current project. The UI is
|
||||||
all tools are only working against the selected project. I can imagine that projects will be separate
|
only showing all data of the current selected project and all tools are only
|
||||||
databases and folders for post and media.
|
working against the selected project. I can imagine that projects will be
|
||||||
|
separate databases and folders for post and media.
|
||||||
|
|
||||||
I want proper full-text search for posts based on the integrated sqlite database using fts5, so that I can
|
I want proper full-text search for posts based on the integrated sqlite
|
||||||
quickly find posts. So build proper text search index update into the core model right away, so that
|
database using fts5, so that I can quickly find posts. So build proper text
|
||||||
regardless how posts come into the system, they are always properly indexed.
|
search index update into the core model right away, so that regardless how posts
|
||||||
|
come into the system, they are always properly indexed.
|
||||||
|
|
||||||
Additionally bring in a good markdown library, because all posts will be formatted in markdown for easy
|
Additionally bring in a good markdown library, because all posts will be
|
||||||
portability to future systems. Media files can be attached to posts and can be referenced with standard
|
formatted in markdown for easy portability to future systems. Media files can be
|
||||||
markdown notation with a post-relative path, so it is easy for the user to include images. The post editor
|
attached to posts and can be referenced with standard markdown notation with a
|
||||||
should support both a wysiwyg editor and raw markdown editor, so the user does not have to know markdown,
|
post-relative path, so it is easy for the user to include images. The post
|
||||||
but everything is handled by the editor, but for complex parts, markdown is available for power users.
|
editor should support both a wysiwyg editor and raw markdown editor, so the user
|
||||||
|
does not have to know markdown, but everything is handled by the editor, but for
|
||||||
|
complex parts, markdown is available for power users.
|
||||||
|
|
||||||
Integrate toasts as notification mechanism that will be used whenever anything has to communicate success/failure to the user.
|
Integrate toasts as notification mechanism that will be used whenever anything
|
||||||
|
has to communicate success/failure to the user.
|
||||||
|
|
||||||
Integrated images in posts should be shown with a lightbox effect als galleries when there are multiple
|
Integrated images in posts should be shown with a lightbox effect als galleries
|
||||||
photos, or just as single images with lightbox when there is only one. The wysiwyg editor should support
|
when there are multiple photos, or just as single images with lightbox when
|
||||||
this at least on a basic level.
|
there is only one. The wysiwyg editor should support this at least on a basic
|
||||||
|
level.
|
||||||
|
|
||||||
## Posting life-cycle
|
## Posting life-cycle
|
||||||
|
|
||||||
New posts start in draft state. Drafts are automatically saved in the background, but the draft content is
|
New posts start in draft state. Drafts are automatically saved in the
|
||||||
not directly part of the publishing pipeline. A user can discard a draft, which either deltes a new post
|
background, but the draft content is not directly part of the publishing
|
||||||
or reverts a post that is edited to the last published state.
|
pipeline. A user can discard a draft, which either deltes a new post or reverts
|
||||||
|
a post that is edited to the last published state.
|
||||||
|
|
||||||
A user can publish a post, that moves the content from the draft state to the published state. Also a user
|
A user can publish a post, that moves the content from the draft state to the
|
||||||
can start editing in a published post, that moves it to draft state with a copy of the original post as
|
published state. Also a user can start editing in a published post, that moves
|
||||||
the starting point.
|
it to draft state with a copy of the original post as the starting point.
|
||||||
|
|
||||||
So essentially posts have two content fields, one for draft and one for published. Editing only happens on
|
So essentially posts have two content fields, one for draft and one for
|
||||||
the draft state. Undo/Redo is also only available on the draft state editing session in the text field
|
published. Editing only happens on the draft state. Undo/Redo is also only
|
||||||
with standard mechanisms.
|
available on the draft state editing session in the text field with standard
|
||||||
|
mechanisms.
|
||||||
|
|
||||||
published posts have a delete button that allows deleting a post that exists. This will internally switch
|
published posts have a delete button that allows deleting a post that exists.
|
||||||
the post to deleted, and filter it out, but will not remove it fully from the database, because the publishing
|
This will internally switch the post to deleted, and filter it out, but will not
|
||||||
pipeline later might need the fact of the deletion as information source to do its thing (update relevant
|
remove it fully from the database, because the publishing pipeline later might
|
||||||
files).
|
need the fact of the deletion as information source to do its thing (update
|
||||||
|
relevant files).
|
||||||
|
|
||||||
So a post starts in "draft" and can go to "published" and from there to "archived". From "draft" it can only
|
So a post starts in "draft" and can go to "published" and from there to
|
||||||
go back to "published" (via discard) or vanish fully from the database (because drafts for new posts are
|
"archived". From "draft" it can only go back to "published" (via discard) or
|
||||||
not relevant for the pipeline, as they never were published before).
|
vanish fully from the database (because drafts for new posts are not relevant
|
||||||
|
for the pipeline, as they never were published before).
|
||||||
|
|
||||||
Posts in draft are automatically saved during edit when idle and a dot in the tab title gives
|
Posts in draft are automatically saved during edit when idle and a dot in the
|
||||||
information about its state as unsaved. The user can force the save with the standard hotkey for that
|
tab title gives information about its state as unsaved. The user can force the
|
||||||
purpose or just wait. Switching to another post will also save a draft automatically.
|
save with the standard hotkey for that purpose or just wait. Switching to
|
||||||
|
another post will also save a draft automatically.
|
||||||
|
|
||||||
Important for the handling of posts is that draft content is always kept in the database and only when
|
Important for the handling of posts is that draft content is always kept in the
|
||||||
the user uses the publish button the content is moved to the filesystem and the content in the database
|
database and only when the user uses the publish button the content is moved to
|
||||||
is set to empty again. This is meant to keep draft content in the database, as it is volatile, and only
|
the filesystem and the content in the database is set to empty again. This is
|
||||||
published content in filesystem, where it is then later used by the publishing pipeline.
|
meant to keep draft content in the database, as it is volatile, and only
|
||||||
|
published content in filesystem, where it is then later used by the publishing
|
||||||
|
pipeline.
|
||||||
|
|
||||||
So only posts in state draft have content in the database, but whenever something goes to state published,
|
So only posts in state draft have content in the database, but whenever
|
||||||
the draft content is set to empty. draft content contains text content as well as metadata content that
|
something goes to state published, the draft content is set to empty. draft
|
||||||
was changed. So even if the user changes tags or the category or the title or whatnot, the actual data
|
content contains text content as well as metadata content that was changed. So
|
||||||
is first only kept in the database and only on publish moved to the file.
|
even if the user changes tags or the category or the title or whatnot, the
|
||||||
|
actual data is first only kept in the database and only on publish moved to the
|
||||||
|
file.
|
||||||
|
|
||||||
Database rebuild at startup is not overwriting draft content, it is only recreating missing posts.
|
Database rebuild at startup is not overwriting draft content, it is only
|
||||||
|
recreating missing posts.
|
||||||
|
|
||||||
Published content is only ever updated when the publish action is done by the user.
|
Published content is only ever updated when the publish action is done by the
|
||||||
|
user.
|
||||||
|
|
||||||
Deletion warns if some media file or post is dependent on the one you are about to delete, because that
|
Deletion warns if some media file or post is dependent on the one you are about
|
||||||
will break the relation.
|
to delete, because that will break the relation.
|
||||||
|
|
||||||
## UI and UX specifics
|
## UI and UX specifics
|
||||||
|
|
||||||
The UI and UX should be aligned with modern applications like vscode. I want iconbar and left sidebar and the
|
The UI and UX should be aligned with modern applications like vscode. I want
|
||||||
big main area with tabbed views. Open views will be automatically opened again on next start, so the user
|
iconbar and left sidebar and the big main area with tabbed views. Open views
|
||||||
does not have to reselect everything.
|
will be automatically opened again on next start, so the user does not have to
|
||||||
|
reselect everything.
|
||||||
|
|
||||||
All sidebar areas and panels can be resized easily and resizings are persisted so they are the same on next
|
All sidebar areas and panels can be resized easily and resizings are persisted
|
||||||
application start. UI configuration is persisted on the project level, so when I switch projects, I get the
|
so they are the same on next application start. UI configuration is persisted on
|
||||||
same layout and opened tabs as the last time I worked on that project.
|
the project level, so when I switch projects, I get the same layout and opened
|
||||||
|
tabs as the last time I worked on that project.
|
||||||
|
|
||||||
Sidebar will be shown/hidden by repeated clicking on same icon, just as with vscode. Also the title bar
|
Sidebar will be shown/hidden by repeated clicking on same icon, just as with
|
||||||
has the typical "show/hide left sidebar" icon as vscode has it.
|
vscode. Also the title bar has the typical "show/hide left sidebar" icon as
|
||||||
|
vscode has it.
|
||||||
|
|
||||||
The main area is a tabbed layout with proper tab support that stay open even on sidebar switching and that
|
The main area is a tabbed layout with proper tab support that stay open even on
|
||||||
grow and shrink accordingly when the sidebar is activated or deactivated.
|
sidebar switching and that grow and shrink accordingly when the sidebar is
|
||||||
|
activated or deactivated.
|
||||||
|
|
||||||
There are no lengthy synchronous actions in the UI thread, everything is offloaded to the main thread and
|
There are no lengthy synchronous actions in the UI thread, everything is
|
||||||
if it is complex, to async tasks, with proper integration with the UI and notification about state of those
|
offloaded to the main thread and if it is complex, to async tasks, with proper
|
||||||
asynchronous tasks via toasts. There is a central notification framework used by everything, so we are sure
|
integration with the UI and notification about state of those asynchronous tasks
|
||||||
that the user is informed about ongoing activities at all times.
|
via toasts. There is a central notification framework used by everything, so we
|
||||||
|
are sure that the user is informed about ongoing activities at all times.
|
||||||
|
|
||||||
There is a bottom status bar in the app that for example shows how many async tasks are running at any time,
|
There is a bottom status bar in the app that for example shows how many async
|
||||||
so if we run maybe two importer in parallel, the user will be able to see that there are 2 tasks running
|
tasks are running at any time, so if we run maybe two importer in parallel, the
|
||||||
and will be abl to click on that to see a small popup that lists all active async tasks.
|
user will be able to see that there are 2 tasks running and will be abl to click
|
||||||
|
on that to see a small popup that lists all active async tasks.
|
||||||
|
|
||||||
All preferences are always local to the selected project and project settings are easily reachable via
|
All preferences are always local to the selected project and project settings
|
||||||
a gear icon in the bottom of the iconbar. Also login credentials can be managed via a user icon in the bottom
|
are easily reachable via a gear icon in the bottom of the iconbar. Also login
|
||||||
of the icon bar directly above the gear icon. This is similar to what vscode does, separating logins and
|
credentials can be managed via a user icon in the bottom of the icon bar
|
||||||
settings.
|
directly above the gear icon. This is similar to what vscode does, separating
|
||||||
|
logins and settings.
|
||||||
|
|
||||||
Tags are something that should be mainly focus on reusing but need easy ways to add new tags. This should
|
Tags are something that should be mainly focus on reusing but need easy ways to
|
||||||
not be a simple text field, but more a feature like tags in gitlab, where you can easily select multiple
|
add new tags. This should not be a simple text field, but more a feature like
|
||||||
available tags, but also can quickly create new tags. Tags should have a color and there should be a way
|
tags in gitlab, where you can easily select multiple available tags, but also
|
||||||
to manage tags in the preferences, too, so that users can create tags upfront to posts.
|
can quickly create new tags. Tags should have a color and there should be a way
|
||||||
|
to manage tags in the preferences, too, so that users can create tags upfront to
|
||||||
|
posts.
|
||||||
|
|
||||||
Categories are a simple selection via dropdown and a preferences panel that allows category management.
|
Categories are a simple selection via dropdown and a preferences panel that
|
||||||
Categories are mainly used to denote different styles of posts and posts are only of one style.
|
allows category management. Categories are mainly used to denote different
|
||||||
|
styles of posts and posts are only of one style.
|
||||||
|
|
||||||
## Organizing
|
## Organizing
|
||||||
|
|
||||||
Blog posts should be organized in the app in the main post view where the sidebar lists posts and the main
|
Blog posts should be organized in the app in the main post view where the
|
||||||
tab area can have multiple posts (new or selected from the sidebar) open, just like vscode manages text files.
|
sidebar lists posts and the main tab area can have multiple posts (new or
|
||||||
The sidebar for posts must also include a calendar view at the top that allows to go to specific dates or
|
selected from the sidebar) open, just like vscode manages text files. The
|
||||||
date ranges (by selecting a whole month of a year for example) and then accordingly filter down the post
|
sidebar for posts must also include a calendar view at the top that allows to go
|
||||||
list in the sidebar.
|
to specific dates or date ranges (by selecting a whole month of a year for
|
||||||
|
example) and then accordingly filter down the post list in the sidebar.
|
||||||
|
|
||||||
And there must be a way to use markdown links of a specific short-form to reference other posts, so that
|
And there must be a way to use markdown links of a specific short-form to
|
||||||
I can link to other places, if needed, and those references should also be part of the information about
|
reference other posts, so that I can link to other places, if needed, and those
|
||||||
posts. So each post should give a "links to" part in the UI (right sidebar or lower area of left sidebar
|
references should also be part of the information about posts. So each post
|
||||||
like with vscode?) and a "linked to by" part where incoming links are shown.
|
should give a "links to" part in the UI (right sidebar or lower area of left
|
||||||
|
sidebar like with vscode?) and a "linked to by" part where incoming links are
|
||||||
|
shown.
|
||||||
|
|
||||||
Post need to support drag-and-drop image insert, and adding images must automatically create the related
|
Post need to support drag-and-drop image insert, and adding images must
|
||||||
media file entry, so that metadata for images can easily be set in the UI, but users get their posts
|
automatically create the related media file entry, so that metadata for images
|
||||||
set up quickly without lots of hassle. Images that are referenced by posts are also linked in metadata to
|
can easily be set in the UI, but users get their posts set up quickly without
|
||||||
the post, so that we have full overview what imags a post references in the actual post data. And that data
|
lots of hassle. Images that are referenced by posts are also linked in metadata
|
||||||
is also included in the published post file on the file system.
|
to the post, so that we have full overview what imags a post references in the
|
||||||
|
actual post data. And that data is also included in the published post file on
|
||||||
|
the file system.
|
||||||
|
|
||||||
Linkage data must be recoverable form posts and image links must be discoverable from post text, too,
|
Linkage data must be recoverable form posts and image links must be discoverable
|
||||||
so that a blog can be repaired if anything goes wrong. There must be a strong focus on being indestructable
|
from post text, too, so that a blog can be repaired if anything goes wrong.
|
||||||
for the blog, the most that could get lost can be draft content, but everything published must be
|
There must be a strong focus on being indestructable for the blog, the most that
|
||||||
fully recoverable from data on the file system.
|
could get lost can be draft content, but everything published must be fully
|
||||||
|
recoverable from data on the file system.
|
||||||
|
|
||||||
### default category "article"
|
### default category "article"
|
||||||
|
|
||||||
This is for articles that are focused on long text. They will show fully only on the full page, but will
|
This is for articles that are focused on long text. They will show fully only on
|
||||||
be summarized in overview pages.
|
the full page, but will be summarized in overview pages.
|
||||||
|
|
||||||
### category "picture"
|
### category "picture"
|
||||||
|
|
||||||
This is a variant of article with less text-focus but usually a strong focus on attached images. This
|
This is a variant of article with less text-focus but usually a strong focus on
|
||||||
will show the image in a wide format if it is just one, or a gallery view, if it is multiple images
|
attached images. This will show the image in a wide format if it is just one, or
|
||||||
and will only show thumbnails for overviews. This means we will need a library to manage image sizes
|
a gallery view, if it is multiple images and will only show thumbnails for
|
||||||
properly for thumbnails during media storage. those thumbnails must be created automatically.
|
overviews. This means we will need a library to manage image sizes properly for
|
||||||
|
thumbnails during media storage. those thumbnails must be created automatically.
|
||||||
|
|
||||||
### category "aside"
|
### category "aside"
|
||||||
|
|
||||||
This is a short-form article that does not need a full-article-page, because it will just be a link and
|
This is a short-form article that does not need a full-article-page, because it
|
||||||
a short comment that is shown after the link. This is meant for link collections and should be rendered
|
will just be a link and a short comment that is shown after the link. This is
|
||||||
in a compact form in the overview pages. More on rendering in the publishing pipelin description.
|
meant for link collections and should be rendered in a compact form in the
|
||||||
|
overview pages. More on rendering in the publishing pipelin description.
|
||||||
|
|
||||||
### category "page"
|
### category "page"
|
||||||
|
|
||||||
This is a post that behaves mostly like an article, but is ignored in overview pages, because it is just
|
This is a post that behaves mostly like an article, but is ignored in overview
|
||||||
meant to be linked to menues. So menu editing needs to be able to reference posts of category page
|
pages, because it is just meant to be linked to menues. So menu editing needs to
|
||||||
and overview templates need to ignore posts of category page. Other than that, they are just like article,
|
be able to reference posts of category page and overview templates need to
|
||||||
so have long form text, short form summary and title. Pages can be assigned different header images that
|
ignore posts of category page. Other than that, they are just like article, so
|
||||||
override the project image.
|
have long form text, short form summary and title. Pages can be assigned
|
||||||
|
different header images that override the project image.
|
||||||
|
|
||||||
### Project definition
|
### Project definition
|
||||||
|
|
||||||
A project is not just the collection of posts, media and publish settings, it is also a base project
|
A project is not just the collection of posts, media and publish settings, it is
|
||||||
container with title, author and other elements like that. So there needs to be project related settings
|
also a base project container with title, author and other elements like that.
|
||||||
that allow to give the project a title, set up a main author that can be referenced in metadat and for
|
So there needs to be project related settings that allow to give the project a
|
||||||
example set up header images that can be used when publishing.
|
title, set up a main author that can be referenced in metadat and for example
|
||||||
|
set up header images that can be used when publishing.
|
||||||
|
|
||||||
## Migrating
|
## Migrating
|
||||||
|
|
||||||
Prepare a proper mass-data importer that can read wordpress backup files, so the user can bring in old
|
Prepare a proper mass-data importer that can read wordpress backup files, so the
|
||||||
wordpress blogs easily. That importer should run asynchronously and properly communicate progress to the
|
user can bring in old wordpress blogs easily. That importer should run
|
||||||
user while it is running in the background. The import has to rebuild all metadata properly, so check if
|
asynchronously and properly communicate progress to the user while it is running
|
||||||
we have all the metadata in our model set up in a similar way as Wordpress handles it, so that we have a
|
in the background. The import has to rebuild all metadata properly, so check if
|
||||||
seamless integration. Posts in Wordpress backups are html, but should be interpreted and transformed into
|
we have all the metadata in our model set up in a similar way as Wordpress
|
||||||
proper markdown in the import.
|
handles it, so that we have a seamless integration. Posts in Wordpress backups
|
||||||
|
are html, but should be interpreted and transformed into proper markdown in the
|
||||||
|
import.
|
||||||
|
|
||||||
In general, HTML elements of the post have to all be transformed into markdown equivalents, and not use
|
In general, HTML elements of the post have to all be transformed into markdown
|
||||||
embedded HTML, for as much as possible. We want clean markdown in the posts after the import, not a mix
|
equivalents, and not use embedded HTML, for as much as possible. We want clean
|
||||||
of markdown and HTML.
|
markdown in the posts after the import, not a mix of markdown and HTML.
|
||||||
|
|
||||||
For this AI support during import to work, the blog application needs to provide post management and media
|
For this AI support during import to work, the blog application needs to provide
|
||||||
management functionality as proper AI tools to the OpenCode Zen API, so that it will be able to work
|
post management and media management functionality as proper AI tools to the
|
||||||
on those posts.
|
OpenCode Zen API, so that it will be able to work on those posts.
|
||||||
|
|
||||||
The AI importing agent must discover the language of a post and put that in an attribute. Posts must have
|
The AI importing agent must discover the language of a post and put that in an
|
||||||
the database structure of translations, so that a post that is discovered as being german can be automatically
|
attribute. Posts must have the database structure of translations, so that a
|
||||||
translated to english and vice-versa. After import, all posts are available in two languages.
|
post that is discovered as being german can be automatically translated to
|
||||||
|
english and vice-versa. After import, all posts are available in two languages.
|
||||||
|
|
||||||
Another thing the AI importing agent must do is create summaries of posts to put into a summary attribute
|
Another thing the AI importing agent must do is create summaries of posts to put
|
||||||
on posts in the database, so that those can be used in overview pages if needed (usually that is the
|
into a summary attribute on posts in the database, so that those can be used in
|
||||||
case for article-type posts).
|
overview pages if needed (usually that is the case for article-type posts).
|
||||||
|
|
||||||
Imports must be able to recognize duplicates of posts to some degree, so that we don't create additional
|
Imports must be able to recognize duplicates of posts to some degree, so that we
|
||||||
posts from new import runs if the original posts are already there. In the case of recognized duplicates,
|
don't create additional posts from new import runs if the original posts are
|
||||||
the original post will just be linked to the same tag of the new import, so that the user can see it was
|
already there. In the case of recognized duplicates, the original post will just
|
||||||
|
be linked to the same tag of the new import, so that the user can see it was
|
||||||
referenced by multiple imports.
|
referenced by multiple imports.
|
||||||
|
|
||||||
Essentially my main idea for imports is that the importer is classes that can read websits from different
|
Essentially my main idea for imports is that the importer is classes that can
|
||||||
sources (starting with wordprss backup and HTTP URL) and that each discovered element is handed to the AI
|
read websits from different sources (starting with wordprss backup and HTTP URL)
|
||||||
to convert to markdown and in the case of the HTTP URL also separate out posts, then use the tools to
|
and that each discovered element is handed to the AI to convert to markdown and
|
||||||
check for duplicates and update tags or create new posts based on the process.
|
in the case of the HTTP URL also separate out posts, then use the tools to check
|
||||||
|
for duplicates and update tags or create new posts based on the process.
|
||||||
|
|
||||||
Import runs can be shown in the main panel, so that the user can see what came with what import and can
|
Import runs can be shown in the main panel, so that the user can see what came
|
||||||
manage posts and media from imports that way. Migration is the main interesting part of this tool, because
|
with what import and can manage posts and media from imports that way. Migration
|
||||||
migrating blogs is hard work and needs to be properly supported.
|
is the main interesting part of this tool, because migrating blogs is hard work
|
||||||
|
and needs to be properly supported.
|
||||||
|
|
||||||
Migrating posts puts them into published state directly, not draft state, because that would make the
|
Migrating posts puts them into published state directly, not draft state,
|
||||||
database explode. The whole point of migration is to get those posts into a published state as soon as
|
because that would make the database explode. The whole point of migration is to
|
||||||
possible.
|
get those posts into a published state as soon as possible.
|
||||||
|
|
||||||
## Organizing II
|
## Organizing II
|
||||||
|
|
||||||
Since we have an AI assistant planned for the migration phase, we also want an AI chat feature as another
|
Since we have an AI assistant planned for the migration phase, we also want an
|
||||||
view in the app, so we can activate it and use the AI assistant to query blog posts and media files in the
|
AI chat feature as another view in the app, so we can activate it and use the AI
|
||||||
system and also create blog posts with AI support.
|
assistant to query blog posts and media files in the system and also create blog
|
||||||
|
posts with AI support.
|
||||||
|
|
||||||
All SDK tools must also be made available as MCP server that is hosted inside the application, so that I
|
All SDK tools must also be made available as MCP server that is hosted inside
|
||||||
can hook the app into a normal AI coding agent.
|
the application, so that I can hook the app into a normal AI coding agent.
|
||||||
|
|
||||||
Also the AI should be available to create summaries just with a button click in the post editor area, so
|
Also the AI should be available to create summaries just with a button click in
|
||||||
that the summary is filled in based on AI summarization to help speed up the blogging process. Also the
|
the post editor area, so that the summary is filled in based on AI summarization
|
||||||
AI can be used to generate a good slurl that is not just generically from the title and even the title
|
to help speed up the blogging process. Also the AI can be used to generate a
|
||||||
can be AI-generated from the text. That way the user can focus on writing the core text and if all matches,
|
good slurl that is not just generically from the title and even the title can be
|
||||||
just accept AI summary and title and post it.
|
AI-generated from the text. That way the user can focus on writing the core text
|
||||||
|
and if all matches, just accept AI summary and title and post it.
|
||||||
|
|
||||||
## Previewing
|
## Previewing
|
||||||
|
|
||||||
There should be an integrated web server that can be opened from the file menu in a browser (menu item
|
There should be an integrated web server that can be opened from the file menu
|
||||||
"open in browser" starts the default browser with the localhost URL) too look at what the site would look
|
in a browser (menu item "open in browser" starts the default browser with the
|
||||||
after publishing. The preview should just run live through what the exporter would do to each page that
|
localhost URL) too look at what the site would look after publishing. The
|
||||||
is sent to the server. This gives a proper preview of things to come.
|
preview should just run live through what the exporter would do to each page
|
||||||
|
that is sent to the server. This gives a proper preview of things to come.
|
||||||
|
|
||||||
Preview should include draft content, so that even before publishing the user can see what will be there
|
Preview should include draft content, so that even before publishing the user
|
||||||
after publishing. Also this will allow background-publishing to automatically happen when new content
|
can see what will be there after publishing. Also this will allow
|
||||||
is put into publish state, if we want that later.
|
background-publishing to automatically happen when new content is put into
|
||||||
|
publish state, if we want that later.
|
||||||
|
|
||||||
## Publishing
|
## Publishing
|
||||||
|
|
||||||
Publishing should target static HTML/CSS/JavaScript situations. There must be a asnyc exporter, that will render
|
Publishing should target static HTML/CSS/JavaScript situations. There must be a
|
||||||
all affected pages based on the structure of the export and auto-update affected files when the posts or media
|
asnyc exporter, that will render all affected pages based on the structure of
|
||||||
that are used in the page were changed. This requires a cross-reference table that links posts and media entries
|
the export and auto-update affected files when the posts or media that are used
|
||||||
with actual HTML files that are referencing them. This needs to be based on how templates use posts in the
|
in the page were changed. This requires a cross-reference table that links posts
|
||||||
export pipeline.
|
and media entries with actual HTML files that are referencing them. This needs
|
||||||
|
to be based on how templates use posts in the export pipeline.
|
||||||
|
|
||||||
Essentially the publishing pipeline knows what posts changed since last publishing (maybe a version number
|
Essentially the publishing pipeline knows what posts changed since last
|
||||||
that is pulled from a central place, so that any change will raise that version and any post and media
|
publishing (maybe a version number that is pulled from a central place, so that
|
||||||
that has a higher version number of the last publish run is seen as changed) and will run the relevant templates
|
any change will raise that version and any post and media that has a higher
|
||||||
to recreate all linkd pages of the publishing (single post pages for the post but also many overview pages) and
|
version number of the last publish run is seen as changed) and will run the
|
||||||
of course each page is only updated once in the publishing run, collecting all changed posts for that.
|
relevant templates to recreate all linkd pages of the publishing (single post
|
||||||
|
pages for the post but also many overview pages) and of course each page is only
|
||||||
|
updated once in the publishing run, collecting all changed posts for that.
|
||||||
|
|
||||||
The main driver is a proper blog structure with templates. For this I want proper templates I can manage and
|
The main driver is a proper blog structure with templates. For this I want
|
||||||
edit in the application itself. Template editing should provide proper syntax highlighting, so something like
|
proper templates I can manage and edit in the application itself. Template
|
||||||
monaco is important. Choose a good solid template engine for node-js based tools that is especialy targeted
|
editing should provide proper syntax highlighting, so something like monaco is
|
||||||
to easy template creation.
|
important. Choose a good solid template engine for node-js based tools that is
|
||||||
|
especialy targeted to easy template creation.
|
||||||
|
|
||||||
For the styling I want the system to be based on css templates, so that the look can be easily swapped
|
For the styling I want the system to be based on css templates, so that the look
|
||||||
to the wish of the user. There should be a selection of light and dark themes bundled with the application,
|
can be easily swapped to the wish of the user. There should be a selection of
|
||||||
so that starting is simple. New css templates must be easily integrateable into the application,
|
light and dark themes bundled with the application, so that starting is simple.
|
||||||
maybe even with easy importing from a central repository site or something like that. I think Pico CSS is a
|
New css templates must be easily integrateable into the application, maybe even
|
||||||
good choice, since it sticks to semantic HTML and auto-adapts to light/dark mode settings of users.
|
with easy importing from a central repository site or something like that. I
|
||||||
I want to work minimalist, but still allow some style influence into the site based on user prefs.
|
think Pico CSS is a good choice, since it sticks to semantic HTML and
|
||||||
|
auto-adapts to light/dark mode settings of users. I want to work minimalist, but
|
||||||
|
still allow some style influence into the site based on user prefs.
|
||||||
|
|
||||||
Check the site https://hugo.rfc1437.de/ for its structure, this is the structure of blog I want to be
|
Check the site https://hugo.rfc1437.de/ for its structure, this is the structure
|
||||||
capable of building with this tooling. So we need templates for overview pages and ways to manage menues
|
of blog I want to be capable of building with this tooling. So we need templates
|
||||||
that reference overview pages and structure the menu according to site structure. Also support calendar views
|
for overview pages and ways to manage menues that reference overview pages and
|
||||||
to allow users to go to specific months and years of the blog. Build up a sensible set of templates that
|
structure the menu according to site structure. Also support calendar views to
|
||||||
come with a new project, so that the user can start right away without a lot of hassle. Base the templates
|
allow users to go to specific months and years of the blog. Build up a sensible
|
||||||
on the structure of above website, but keep out website title and images, of course.
|
set of templates that come with a new project, so that the user can start right
|
||||||
|
away without a lot of hassle. Base the templates on the structure of above
|
||||||
|
website, but keep out website title and images, of course.
|
||||||
|
|
||||||
Categories and tags must be able to define a template selection for post templates, so that different types
|
Categories and tags must be able to define a template selection for post
|
||||||
can be represented differently. this is especially important for the standard categories "article", "picture"
|
templates, so that different types can be represented differently. this is
|
||||||
and "aside", as they should come right away with templates for their article page and their use in overviews.
|
especially important for the standard categories "article", "picture" and
|
||||||
Every post can define via category or tag (tag-related templates override category templates but can be
|
"aside", as they should come right away with templates for their article page
|
||||||
overridden via article-specific template selections).
|
and their use in overviews. Every post can define via category or tag
|
||||||
|
(tag-related templates override category templates but can be overridden via
|
||||||
|
article-specific template selections).
|
||||||
|
|
||||||
There must be way to open a browser tab in the application that then uses the applicaiton itself and does
|
There must be way to open a browser tab in the application that then uses the
|
||||||
dynamic rendering of the content, using the same templates and everything else, so that the user can do
|
applicaiton itself and does dynamic rendering of the content, using the same
|
||||||
a propoer preview before deciding to update the remote static web storage. The browser tab will of course use
|
templates and everything else, so that the user can do a propoer preview before
|
||||||
the correct styling of the website.
|
deciding to update the remote static web storage. The browser tab will of course
|
||||||
|
use the correct styling of the website.
|
||||||
|
|
||||||
Publishing of files can be configured to be done via FTP or SSH, connection data must be configureable in
|
Publishing of files can be configured to be done via FTP or SSH, connection data
|
||||||
preferences for the website.
|
must be configureable in preferences for the website.
|
||||||
|
|||||||
Reference in New Issue
Block a user