Управление биллингом не через HTTP

[Sergius]

И так: есть авторизатор-программа для абонента.

Многими биллингами управляют из-под программы для администратора.
Это нужно для того если Ваш администратор или работник не имеет прямого доступа к сети, но ему нужно управлять биллингом. (не через http)

Я думаю разработчик понимает что я хочу сказать.

Есть-ли хотя бы задумки на данную тему в будущем?

[Cell]

Это нужно для того если Ваш администратор или работник не имеет прямого доступа к сети, но ему нужно управлять биллингом. (не через http)

Не могу себе придумать ни одного случая подобного ))))
Ихмо вебадминка - это огромный плюс для биллинга так-как в сттотысячмилионнов раз упрощает управление как раз не из сети. А разработчику есть чего делать из нормальных фитчей а не фигней заниматься.

[Efendy]

Если нет доступа по http - это нонсенс, неужели у админа нет малехонького ноутбука с линуксом? Управление через иную программу вижу даже вредным - придется делать пересекающиеся фичи и там и там, вероятность ошибки повысится. Особого удобства не доставит

[Sergius]

У нас в москве - есть сети в которых доступ к статистике и к биллингу только внутри сети!
Поэтому и получается что по протоколу http не проходит. А по программе можно зайти. Так как многие пров. блочат порты.

[Cell]

У нас в москве - есть сети в которых доступ к статистике и к биллингу только внутри сети!
Поэтому и получается что по протоколу http не проходит. А по программе можно зайти. Так как многие пров. блочат порты.

Бред. Провайдер -- сам себе режиссер. Какой порт открыл, такой и будет. Можно даже пробросить левый порт на https, например какой-нибудь 61873 )))

[Fredik]

однозначно не нужна программа, переходя со старгейзера на нодени сначало сложилось впечетление что работать неудобно в вебе, но когда гдето вне дома, можна зайти с любого телефона, любого компа и все посмотреть, щет пополнить, заблокировать и все такое. а в Старгейзере нада было ставить доп модуль администратирования через веб. и + он немного карявенький был.

[Cell]

нада было ставить доп модуль администратирования через веб. и + он немного карявенький был.

"немного" это громко. Он был кривой на всю голову, бывали мы и там )))

[t0ly]

думаю речь идёт об rpc
например можно написать cgi и повесить его на отдельном порту с ssl и авторизацией.

[versus]

Если делать RPC  тогда конечно можно любых клиентов писать, но дело в том что для рпц придется сделать унифицированный апи и следить за ним когда вносятся изменения в работу биллинга!  Конечно можно  переписать всю вэбморду на обращении к этому рпц, но овчинка выделки не стоит - купят такой модуль еденицы, увеличивать стоимость биллинга при включении данной фичи не хотим! Переводить на ее реализацию  ресурсы не вижу смысла!
Если кто то захочет, то сделает самостоятельно.

[t0ly]

вообще как мне кажется унифицированное api должно наоборот удишивить продукт, как в плане использования так и вплане доработок различных модулей и сервисов.
я ошибаюсь?

[Fredik]

это будет новинка, как у старгейзера веб интерфес который вечо дорабатывали так и тут, я щитаю что для начала нада допилить билинг а потом братся за удобства.

[versus]

вообще как мне кажется унифицированное api должно наоборот удишивить продукт, как в плане использования так и вплане доработок различных модулей и сервисов.
я ошибаюсь?

Я не вижу как можно удишевить продукт написанием рпц апи! Может подскажете неграмотному?
Есть стоимость работы программиста, есть продажи биллинга, есть апи рпц - ваш рецепт удишевления  стоимости можете написать?
Что касается доработки модулей и сервисов то с этим отлично справляется апи для плагинов, что дало возможность дописывать функционал как в клиентской части, так и в в админской!

[t0ly]

скорее всего мы друг дрега не поняли.

[Efendy]

БД - это по сути и есть API. Вы можете написать графическое приложение, которое по логину/паролю будет коннектиться к БД и вносить там изменения. Даже посылка сигналов ядру делается через БД

[goletsa]

Теоретически можно написать демон который бы висел в памяти и напрямую обращался к базе.

Но это достаточно запарно будет.

Плюс надо будет поддерживаь клиент к демону...

Плюс клиент наверняка будет платформозависим.

Про java не напоминайте - я до сих пор помню как у utm тормазит их клиент.