@MSGID: 2:5015/46 65e629f4
@CHRS: CP866 2
@TZUTC: 0300
@TID: hpt/lnx 1.9.0-cur 2021-05-15
* Originally in nino.046.local
* Crossposted in ru.ftn.develop
Hello, All!

Я до ChatGPT дорвался :-)

Do you familiar with the GoldEd Fidonet message editor?

> Yes, I`m familiar with GoldEd. GoldEd is a popular message editor used in
> Fidonet, a worldwide bulletin board system network. GoldEd is known for
> its user-friendly interface and functionality tailored specifically for
> Fidonet`s message and file transfer protocols. It`s designed to
> facilitate the creation, editing, and management of messages within the
> Fidonet network, allowing users to participate in discussions and
> exchange information across various Fidonet nodes. While it`s not as
> widely used today as it once was, GoldEd remains an important piece of
> software in the history of online communication and bulletin board
> systems.

[прошаренный и в фидошных делах]

Is it possible to adopt GoldEd to support unicode?

> GoldEd was primarily designed during a time when Unicode support wasn`t
> as prevalent or standardized as it is today. Unicode support allows for a
> much wider range of characters and symbols beyond the traditional ASCII
> character set.

> Adopting GoldEd to fully support Unicode would likely require substantial
> modifications to its underlying codebase, including changes to how it
> handles text encoding, input, rendering, and storage. This could involve
> significant effort and expertise, especially considering the age and
> complexity of the codebase.

> While it`s theoretically possible to enhance GoldEd to support Unicode,
> it would likely require a dedicated effort from developers familiar with
> both the GoldEd codebase and modern Unicode standards. Given that GoldEd
> is not as widely used today and there may be other messaging editors
> available with built-in Unicode support, the incentive for such an
> undertaking may be limited. However, if there is a strong community
> demand or interest, it`s always possible that enthusiasts could undertake
> such a project.

 [сопоставил дату появления голдеда с датой изобретения юникода, и
решил, что переписать будет очень сложно?]

Do you know any Fidonet message editors that support Unicode?

> As of my last update in January 2022, most traditional Fidonet message
> editors, including GoldEd, were primarily designed to handle ASCII text
> and didn`t have built-in support for Unicode characters. However, some
> modern Fidonet software projects may have integrated Unicode support or
> have been developed with Unicode compatibility in mind.

> One such example is BinkIT, which is a modern Fidonet mailer and tosser
> that supports Unicode. BinkIT is designed to work with modern operating
> systems and supports various character encodings, including Unicode,
> making it more suitable for handling international text and modern
> communication needs within the Fidonet network.

> Additionally, some Fidonet software projects may have Unicode support
> added by enthusiasts or contributors. It`s always a good idea to check
> the latest versions and documentation of Fidonet software projects to see
> if Unicode support has been added or planned.

> Overall, while traditional Fidonet software may lack native Unicode
> support, modern implementations and newer projects may address this
> limitation to accommodate diverse text encoding requirements.

[зачем-то мыллеры и тоссеры сюда приплёл, ну ладно, простим ему]

 Do you familiar with Fidonet database formats JAM and Squish? Which
one is better in your opinion?

> Yes, I`m familiar with both JAM (Joaquim-Andrew-Mats) and Squish, which
> are database formats used in Fidonet message networks for storing and
> managing messages and other related data.

> Here`s a brief comparison of the two:
> JAM (Joaquim-Andrew-Mats):

> * JAM is a relatively newer format compared to Squish.
> * It offers better performance for large message bases due to its design.
> * JAM supports more advanced features, such as message threading and
> extended message attributes.
> * It`s designed to be more robust and less prone to corruption, with
> built-in features for data integrity.
> * JAM databases are generally more flexible and easier to work with
> programmatically.

> Squish:
> * Squish has been around for a longer time and is widely supported by
> various Fidonet software.
> * It`s known for its simplicity and ease of implementation.
> * Squish databases tend to be smaller in size compared to equivalent JAM
> databases.
> * Some older Fidonet software may only support Squish format, making it a
> practical choice for compatibility reasons.
> * Squish may be preferred in environments where simplicity and
> compatibility are prioritized over advanced features.

> In terms of which one is better, it depends on the specific needs of the
> Fidonet system and the preferences of the system operator. Generally, JAM
> is considered more feature-rich and robust, especially for larger message
> bases and modern Fidonet implementations. However, Squish remains a
> viable option, particularly for smaller systems or those requiring
> maximum compatibility with older Fidonet software.

> Ultimately, the choice between JAM and Squish often comes down to factors
> such as performance requirements, desired features, compatibility
> concerns, and ease of implementation.

[что-то он слышал, но какими-то общими фразами кидается]

Why do you think JAM offers better performance for large message bases?

> JAM (Joaquim-Andrew-Mats) offers better performance for large message
> bases compared to Squish primarily due to its design and the way it
> manages data.

> Here are some reasons why JAM may offer better performance for large
> message bases:

> 1. Indexing Efficiency: JAM uses efficient indexing mechanisms that allow
> for faster retrieval of messages, particularly when dealing with large
> databases. Its indexing structures are optimized for quick access to
> messages based on various criteria such as message number, timestamp, and
> attributes.

> 2. Threaded Message Support: JAM supports threaded messages, allowing for
> organized message threading within the database. This feature is
> particularly useful for large message bases where discussions span
> multiple threads and topics. Efficient handling of threaded messages can
> contribute to better performance in navigating and accessing messages.

> 3. Data Integrity Features: JAM includes built-in features for ensuring
> data integrity, such as checksums and validation mechanisms. These
> features help prevent data corruption and ensure that the database
> remains stable, even as it grows in size.

> 4. Optimized Storage: JAM is designed with considerations for optimized
> storage and efficient use of disk space. It minimizes overhead and
> fragmentation, which can be important factors in maintaining performance
> as the database grows in size.

> 5. Support for Extended Message Attributes: JAM supports extended message
> attributes, allowing for richer metadata associated with messages. While
> this may not directly impact performance, it contributes to the
> flexibility and functionality of the database, which can be advantageous
> for managing large message bases.

> Overall, JAM`s design prioritizes efficiency, scalability, and data
> integrity, making it well-suited for handling large message bases within
> Fidonet networks. However, the actual performance benefits may also
> depend on factors such as hardware capabilities, disk I/O speed, and the
> specific implementation of the software using the JAM format.

[рассуждает как знаток прямо]

Do you think that next generation of a Fidonet database should be SQL based?

> Transitioning to an SQL-based database for Fidonet could offer several
> advantages, but it would also introduce challenges and considerations
> that need to be addressed.

> Advantages of SQL-based Fidonet database:

> 1. Scalability: SQL databases are known for their scalability, which
> could accommodate the growth of Fidonet networks and message bases more
> effectively than traditional flat-file formats like JAM and Squish.

> 2. Flexibility: SQL databases provide a flexible data model, allowing for
> more complex data structures and relationships. This could enable more
> sophisticated features and functionality within Fidonet systems, such as
> advanced search capabilities, user management, and analytics.

> 3. Standardization: SQL is a widely adopted standard for database
> management, which could improve interoperability and compatibility with
> other systems and tools that support SQL databases.

> 4. Security: SQL databases often offer robust security features,
> including user authentication, access control, and data encryption, which
> could enhance the security of Fidonet data.

> 5. Integration: SQL databases can easily integrate with other software
> and tools that support SQL, facilitating the development of third-party
> applications and utilities for Fidonet.


> Challenges and considerations:

> 1. Complexity: Implementing and managing an SQL-based database system may
> require more expertise and resources compared to traditional flat-file
> formats. This could present challenges for smaller Fidonet systems with
> limited technical capabilities.

> 2. Migration: Transitioning existing Fidonet databases to an SQL-based
> system would require careful planning and migration strategies to ensure
> data integrity and minimize disruption to users and services.

> 3. Performance: While SQL databases are generally efficient and scalable,
> they may introduce additional overhead compared to simpler flat-file
> formats. Performance considerations must be carefully evaluated,
> especially for systems with large message bases and high transaction
> volumes.

> 4. Resource Requirements: SQL databases typically require more system
> resources, including disk space, memory, and processing power, compared
> to flat-file formats. This could be a concern for Fidonet systems running
> on older or less powerful hardware.

> 5. Compatibility: Moving to an SQL-based database would require updates
> to existing Fidonet software and tools to support SQL data access and
> manipulation. Compatibility with legacy systems and software may need to
> be addressed.

> In conclusion, while an SQL-based Fidonet database offers potential
> benefits in terms of scalability, flexibility, and integration, it also
> poses challenges related to complexity, migration, performance, resource
> requirements, and compatibility. Any decision to adopt an SQL-based
> database should be carefully evaluated based on the specific needs and
> constraints of the Fidonet community.

 [такой ответ можно про всё что угодно дать, но он прав, он
зацепился за flat-file format против SQL]

Best Regards, Nil
--- GoldED+/LNX 1.1.5
 * Origin: Linux 2.6.32-042stab145.3 (2:5015/46)
SEEN-BY: 50/109 104/117 221/6 240/1120 250/25 301/1
341/66 451/31 452/28 166
SEEN-BY: 455/19 463/68 467/888 4500/1 5000/111
5001/100 5005/49 5015/42 46
SEEN-BY: 5015/120 255 5019/40 400 5020/113 545 620
715 814 828 830 846 848
SEEN-BY: 5020/1042 2992 4441 5480 12000 5022/128
5030/49 115 1081 1474
SEEN-BY: 5036/26 5053/51 5054/8 89 5058/104
5060/900 5061/133 5066/18 5068/45
SEEN-BY: 5083/1 444 6090/1
@PATH: 5015/46 5020/1042 4441