Болтаем с ChatGPT о голдеде, базах, т.д.

Nil A написал(а) к All в Mar 24 22:48:48 по местному времени:

* Originally in nino.046.local
* Crossposted in ru.ftn.develop
Нello, 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. Нowever, 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. Нowever, 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.

> Нere'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. Нowever, 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.

> Нere 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. Нowever, 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

Dmitry Protasoff написал(а) к Nil A в Mar 24 20:27:51 по местному времени:

Нello, Nil!

Monday March 04 2024 22:48, you wrote to All:

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

У меня другие ответы!

User
Do you familiar with the GoldEd Fidonet message editor?
ChatGPT

Yes, I'm familiar with GoldEd, a popular message editor for FidoNet. FidoNet is a worldwide computer network that is used for communication between bulletin board systems (BBSs). It was most popular during the 1980s and early 1990s, before the widespread adoption of the Internet. GoldEd is one of the many software tools developed for FidoNet users, designed for creating and editing messages to be sent over the network.

GoldEd is known for its extensive feature set, including a powerful text editor, support for multiple message areas, and a range of configuration options to tailor the user experience. It was designed to work with various message bases (the format in which messages are stored) and to be highly customizable to fit the needs of different users. Over the years, there have been several versions and forks of GoldEd, including GoldEd+ (GoldEd Plus), which incorporated additional features and improvements.

User
Is it possible to adopt GoldEd to support unicode?
ChatGPT

Adopting GoldEd to support Unicode would be technically possible but would require significant modifications to the program. The original GoldEd was developed during a time when Unicode was not widely adopted or supported, and it was primarily designed to work with the character encoding standards of the time, such as ASCII and possibly extended ASCII for specific locales. Unicode support would allow the editor to handle a much wider range of characters from virtually all written languages, which would be a significant improvement for global communication.

To add Unicode support to GoldEd, several key areas of the program would need to be updated:

Text Storage and Processing: The internal mechanisms for storing, retrieving, and processing text would need to be updated to handle Unicode characters. This could involve significant changes to the way messages are stored in memory and on disk.

User Interface: The user interface would need to be capable of displaying Unicode characters correctly. This might involve updates to the text rendering engine and ensuring compatibility with fonts that support a wide range of Unicode characters.

Input Methods: Support for input methods that allow users to type characters from various languages not directly supported by their keyboard layouts would be necessary.

Message Encoding: When sending and receiving messages via FidoNet or other networks, the software would need to ensure that Unicode messages are correctly encoded and decoded. This could involve implementing support for UTF-8 or another Unicode encoding scheme and ensuring compatibility with systems that may not support Unicode.

Compatibility: Maintaining backward compatibility with existing messages and systems that do not support Unicode would be an important consideration. This might involve implementing features to automatically detect and convert between different encoding standards.

Given that GoldEd is an older software, making these changes would require access to the source code and a good understanding of both the software's architecture and Unicode standards. It would be a non-trivial project that would likely involve a substantial amount of work. Нowever, if there is a strong demand within the FidoNet community or among users of similar systems, and if developers with the necessary skills and interest can be found, it's certainly within the realm of possibility.


Ну и дальше отличается.

Best regards,
dp.

--- GoldED+/LNX 1.1.5-b20230304

Nil A написал(а) к Dmitry Protasoff в Mar 24 00:03:58 по местному времени:

Нello, Dmitry!

Monday March 04 2024 20:27, from Dmitry Protasoff -> Nil A:

NA>> Я до ChatGPT дорвался :-)
DP> У меня другие ответы!

3.5 бесплатный или 4.0 платный?

Best Regards, Nil
--- GoldED+/LNX 1.1.5

Dmitry Protasoff написал(а) к Nil A в Mar 24 22:04:54 по местному времени:

Нello, Nil!

Tuesday March 05 2024 00:03, you wrote to me:

NA>>> Я до ChatGPT дорвался :-)
DP>> У меня другие ответы!

NA> 3.5 бесплатный или 4.0 платный?

Платный 4.0.

Best regards,
dp.

--- GoldED+/LNX 1.1.5-b20230304