Проект "Интерфейс SC памяти"

Сообщение ZhitkoVA » 19 ноя 2011, 11:10
Проект создан на github http://github.com/zhitko/ostis-memory-interface
Wiki проекта http://github.com/zhitko/ostis-memory-interface/wiki

В теме обсуждаем требования к проекту для внесения в документацию к проекту.

ZhitkoVA


Сообщение DenisKoronchik » 19 ноя 2011, 17:59

    Проект "Интерфейс доступа к реализации SC памяти" Система организует унифицированный доступ к различным реализациям SC памяти, предоставляет возможность создания SC агентов на различных языках программирования, обеспечивает многопоточность, механизм транзакций.



Почему интерфейс доступа к реализации sc-памяти? Речь совсем не об этом, и это обсуждалось. Речь о реализации sc-памяти, которая абстрагируется от способа хранения sc-коснтрукций (sc-хранилища).

Что за механизм транзакций? Зачем он тут?

Что за требование "многопоточность"?
Откуда требование "реализация" на c++? Почему с++? Чистый си куда лучше, ибо к нему проще потом делать биндинги на любые языки, над которым потом можно надстроить и с++ (объектно ориентированный). Так делается везде.

    Система предназначена для организации взаимодействия реализаций SC агентов и реализаций SC памяти, не завися от их конкретных вариантов реализаций.


Из этой строчки ничего непонятно что и зачем. Лучше не называть это системой, а типа "Основной целью проекта является ..."
Назначение - моделирование sc-памяти, которая поддерживает ассоциативный доступ

    требования к программной документации: документация


А это к чему?

DenisKoronchik


Сообщение ZhitkoVA » 20 ноя 2011, 15:12
Речь не шла о реализации sc памяти.

Остальные замечания не о чем.

ZhitkoVA


Сообщение DenisKoronchik » 20 ноя 2011, 15:19
Стоп мы обсуждаем? Или уже есть готовы проект?
Почему замечания ниочем? Да и там не только замечания, но и вопросы.

DenisKoronchik


Сообщение ZhitkoVA » 21 ноя 2011, 13:14
Ок. Буду подробней.

    DenisKoronchik писал(а):

        Проект "Интерфейс доступа к реализации SC памяти" Система организует унифицированный доступ к различным реализациям SC памяти, предоставляет возможность создания SC агентов на различных языках программирования, обеспечивает многопоточность, механизм транзакций.



    Почему интерфейс доступа к реализации sc-памяти? Речь совсем не об этом, и это обсуждалось. Речь о реализации sc-памяти, которая абстрагируется от способа хранения sc-коснтрукций (sc-хранилища).


Это нельзя назвать реализацией sc памяти.
Термин sc-хранилища мы ни разу не использовали, мы это называем sc-память.

    DenisKoronchik писал(а):Что за механизм транзакций? Зачем он тут?


По мне, нечто подобное должно быть, как и поддержка одновременного доступа нескольких приложений.

    DenisKoronchik писал(а):Что за требование "многопоточность"?


Что за что за требование, поясни.

    DenisKoronchik писал(а):Откуда требование "реализация" на c++? Почему с++? Чистый си куда лучше, ибо к нему проще потом делать биндинги на любые языки, над которым потом можно надстроить и с++ (объектно ориентированный). Так делается везде.


Доводы, почему надо именно так, только не надо опять так везде, так мне кто-то умный сказал, конкретней.

    DenisKoronchik писал(а):

        Система предназначена для организации взаимодействия реализаций SC агентов и реализаций SC памяти, не завися от их конкретных вариантов реализаций.


    Из этой строчки ничего непонятно что и зачем. Лучше не называть это системой, а типа "Основной целью проекта является ..."
    Назначение - моделирование sc-памяти, которая поддерживает ассоциативный доступ


"Основной целью проекта является ..." - с этим согласен.
Назначение - моделирование sc-памяти, которая поддерживает ассоциативный доступ - этот проект не о моделировании памяти.

    DenisKoronchik писал(а):

        требования к программной документации: документация


    А это к чему?


А каково трое предложение к списку документации к проекту?
Хотя, этот пункт тоже надо бы убрать.

ZhitkoVA


Сообщение DenisKoronchik » 22 ноя 2011, 12:00
Предлагаю называть это scAPI.

Разговор состоялся в устной форме, но для протокола напишу.
Что касается многопоточности и механизма транзакций, то это необходимо опускать на уровень ниже, в саму память над которой надстраивается интерфейс. Так как именно там целесообразно этим заниматься по причине того, что синхронизация (эффективная) может быть сделана лишь с учетом того, как представляются конструкции в памяти.

Что касается реализации на си, то довод очень простой - простая возможность дальнейшего использования в различных языках, через биндинги.
При этом таким должен быть лишь API. Внутри обертка может быть написана и на с++.

DenisKoronchik