Aplikacja z serwerem centralnym, jak podejść do tematu Opcje

[athabus]

Witam,

przymierzam się do projektu, serwisu ogłoszeniowego, tyle że dość nietypowego. Chodzi w skrócie o to, aby serwis posiadał centralną bazę danych, ale działał jako dziesiątki niezależnych serwisów. Idea jest taka, że każdy kto będzie chciał będzie mógł sobie postawić na subdomenie taki serwis z częścią lub całością contetntu, która będzie interesowała użytkowników jego witryny + możliwością wykonywania akcji typu dodawanie ogłoszeń (które będą widoczne także na pozostałych stronach biorących udział w wymianie), ocenianie ich itp. Czyli innymi słowy dla postronnego użytkownika odwiedzającego tą strone ma być zwykły serwis ogłoszeniowy.

Problem jaki chcę przeskoczyć to prostota instalacji. Tj. aby osoba, która będzie chciała uruchomić taki serwis mogła to zrobić na zasadzie utworzenia subdomeny i wgrania plików, bez konieczności hostowania bazy, dbania o aktualizacje itp. W aplikacji przewiduje jedynie ingerencję w warstwę wizualną, czyli drobne modyfikacje html szablonu (np. stopki/headera) czy zmianę styli - żadnych zmian w kodzie php itp. W zasadzie takie rzeczy mogłyby być także przechowywane na serwerze centralnym, który serwowałby gotową do wyświetlenia stronę

Teraz pytanie jak najprościej osiągnąć taki efekt? Przychodzi mi do głowy prosta aplikacja php, która będzie pobierała na podstawie url'a całą treść strony z serwera centralnego (powiedzmy przez file_get_content), a wszelkie żądania POST itp serializować i wysyłać do serwera centralnego w kwestii obróbki, ale pewnie można to jakoś bardziej elegancko rozwiązać. Może zrobić klienta w Java Script?

Dodam, że chodzi także o uniwersalność rozwiązania, tak aby można je było odpalić (mowa o wersji klienta, nie serwera centralnego) na każdej standardowej konfiguracji serwera współdzielonego.

PS. Nie będę tego sam pisał - chcę tylko ogarnąć zagadnienie na tyle, aby móc napisać w miarę przyzwoitą wstępną specyfikację.

[athabus]

Chyba po prostu myślisz o zbyt rozbudowanej aplikacji ;-)

Widzisz, bo tutaj cały problem polega właśnie na tym, że rozwiązanie z SOAP jest po prostu zbyt rozbudowane. Mówiąc wprost produkt będzie przeznaczony "dla Pani Czesi", która prowadzi bloga i chciałaby go wzbogacić o ogłoszenia w swojej tematyce. Opcje jakie będzie potrzebowała pani Czesia to w skrócie:
- ewentualne ograniczenie wyświetlanych kategorii (czyli np. wyświetla tylko ogłoszenia o tematyce x i tylko od swoich znajomych)
- być może (co jest bardzo wątpliwe) p. Czesia będzie chciała trochę upodobnić kolorystycznie ogłoszenia do swojego bloga, lub np. dodać w nagłówku "ogłoszenia Pani Czesi"
Obie te rzeczy Pani Czesia będzie mogła zrobić w panelu na serwerze centralnym. Jak już na prawdę będzie miało być full wypas, to pani Czesia będzie mogła edytować css (też pewnie nie jako plik, ale jako wpis do bazy danych).

Pani Czesia natomiast na pewno nie będzie zainteresowana integracją tego ze swoim blogiem, nie będzie chciała programować, grzebać w API itp.

Czyli jednym słowem, rozumiesz - to nie ma być profesjonalna elastyczna aplikacja, tylko dodatek do bloga/strony, który będzie posiadał minimalne opcje konfiguracyjne, ale za to będzie banalnie prosty do zainstalowania, nawet dla osoby, która nie potrafi nic zrobić samodzielnie w temacie. W skrajnej wersji przewiduję nawet hostowanie subdomeny na własnym serwerze, tak że Pani Czesia jedynie zmieni wpis w rekordach domeny w panelu swojego providera.

Tak na prawdę chodziłoby mi o coś takiego, że klient tylko wysyła żądanie do serwera centralnego po kliknięciu linku coś w stylu {user: czesia; url: abc/add; POST:[...] } i otrzymuje gotową stronę w oparciu o ustawienia użytkownika Czesia. Jedyne co komplikuje sprawę, to to, że użytkownicy na stronie p. Czesi:
- mogą się logować
- dodawać treści/edytować je
- oceniać te treści
itp. Czyli ogólnie wszystko to co robi się na serwisach ogłoszeniowych i ma to być transparentne, tak aby gość Pani Czesi nie wiedział, że tak na prawdę działa na serwerze centralnym.