Parlant del projecte amb un amic ens han sorgit plantejaments com els que detallo a continuació.
1. Enviament de les dades del mòbil al servidor.
Cada vegada que es duu a terme la sincronització de dades necessitarem enviar els nous esdeveniments generats al servidor, per fer-ho en principi tenim un string que ens emmagatzema la informació a enviar. Aquesta informació està emmagatzemada amb els corresponents tags XML. De manera que si per a un esdeveniments no coneixem tots els seus paràmetres, només enviarem aquells coneguts amb els tags corresponents.
Fins ara tot sembla correcte, però si ens parem a pensar ens podem trobar de que estem enviant massa informació al servidor, per tant el paquet de dades és més gran per què cada tag apareix com a mínim dues vegades.
Una alternativa plantejada seria enviar les dades separades per comes en comptes de per tags. Ara tindríem que enviar una coma per cada paràmetre que enviem al servidor. De manera que si desconeixem una característica del esdeveniment en el seu lloc col·locarem una coma i el servidor ha de ser capaç de interpretar que aquell camp es troba buit. Per tant podríem formar el XML al servidor.
Al separar-lo per comes podem estar reduint a la meitat el nombre de dades a enviar.
Caldria tenir present possibles problemes de velocitat en la generació / tractament de arxius XML en el dispositiu mòbil.
2. Programació part del servidor
Fins ara tenia molt clara la idea de programar la part del servidor en PHP. No s'han analitzat en profunditat els temes d'arquitectura corresponents, però resultava interessant fer treballar dos llenguatges diferents. Però per altre banda ens trobem que el PHP no ens permet debugar.
Una alternativa seria fer-ho en Java, passaríem a treballar en el fons en el mateix llenguatge sols que aplicat a arquitectures hardware diferents. Tot hi que ens podem trobar que el tomcat ens doni problemes.
3. Gestió de la base de dades
Per ara hi ha tres possibles opcions, el que no implica que les tres siguin vàlides.
a. gestionar la base de dades "a pèl" a base de SQL
b. Propel
c. Hibernate
4. Gestió del tema de seguretat
S'han plantejat opcions com encriptació amb keypair i SSL...
5. Gestió de login
Cada vegada que un usuari es logegi tindrem que dur a terme una gestió. Una de les coses que ens pot ajudar a decidir entre PHP o JAVA seria l'existència de una API que ens permetés dur a terme la gestió d'aquest login.
Alguna idea més?
miércoles, 30 de enero de 2008
Plantejaments
Suscribirse a:
Enviar comentarios (Atom)
1 comentario:
Sobre 1)
L'ús de XML standaritza el tractament de fitxers, en contra del que fa el tractament de fitxers separats per comes, punts i comes o altres caràcters ($, #...).
Desenvolupar un scanner (analitzador lèxic, per a fer tractament de fitxers separats per comes no cal un parser o analitzador sintàctic) per a fer el tractament dels fitxers q arribin a la banda de servidor seria molt més costós en termes de temps.
A més, amb les actuals tarifes de dades en telefonia mòbil no resulta car, tenint en compte que les operadores podrien subvencionar una part de la connexió com fa Movistar amb el seu nou servei de còpia de l'agenda de contactes.
Addicionament, si tenim en compte que s'aplicaran diverses polítiques de reescriptura (per exemple: no s'enviaran els esdeveniments passats cap al servidor o que el servidor només enviarà cap al dispositiu mòbil els esdeveniments de la propera setmana), la quantitat de text a trametre és molt baixa. El que sí que seria un abona idea és re-dissenyar els tags per a que fossin més curts i reduir així l'overhead, a la manera que ho fa CTHML (Compact-HTML, enlloc de posar < event > es posaria < ev >, per exemple).
En definitiva, el tractament de text separat per comes complicaria el desenvolupament del projecte i limitaria la seva interoperatibilitat amb altres sistemes (tots els llenguatges tenen parsers d'XML o llibreries q ho permeten fer fàcilment sense haver de repicar el scanner en cada llenguatge. De fet, segons les meves estimacions, el tractament de l'XML no seran més de 10 linies de codi.
D'altra banda, no sé quina és la idea que té la gent de l'XML, però un document XML és un string en text pla amb entitites HTML en cas necessari. Ara mateix la construcció de l'XML a la banda de dispositiu mòbil ja està feta i és funcional al 100%. Si el problema és l'XML que rebrà el dispositiu mòbil des del servidor, es processarà molt més ràpid si es desactiva la seva validació al dispositiu mòbil. D'aquesta manera es millorarà el rendiment.
Sobre 2) i 3)
Java pot ser una plataforma molt estesa i q pot funcionar molt bé per a projectes corporatius enormes, però no ens podem sortir de mare. M'explico: no hem d'adaptar el problema a la solució q sabem (això és el q fan les consultores tecnològiques) sinó solucionar el problema q tenim.
Tota la part de servidor desenvolupada en PHP (inclosa la connexió contra la base de dades) seran 4 fitxers funcionant sobre un apache 2.2 (això sí q és multiplataforma, que no s'ha ni de recompilar). Sobre Java és impossible fer-ho així (has de fer javac per a cada plataforma objectiu, per exemple).
De fet, l'ús de frameworks com Hibernate dificulta la feina en aquest cas. Si no es necessiten, no s'han de fer servir perquè afegeixen una complexitat innecessària al projecte i poden produir errors addicionals. És el principi KISS (Keep It Simple, Stupid!) que les consultores no saben mai aplicar.
Hibernate està bé quan vols q algú et gestioni "automàticament" un munt de classes diferents que van a parar a diferents taules. Però si només vols enmagatzemar 1 tipus d'objectes, per a què coi vols Hibernate? Un insert contra una BD Relacional clàssica és molt més senzill i fa el mateix servei.
La limitació en el debugging de PHP és certa, però no és insalvable. De fet, sí q permet debuggar en programets petits com el que resultarà. Tenint en compte això, juntament amb que PHP simplifica molt les connexions contra BDs i la rapidesa en el desenvolupament, aquest hauria de ser el llenguatge escollit.
Sobre 4)
HTTPS serà el protocol escollit per a la "posada en producció". A J2ME, es fa de la mateixa manera que una connexió HTTP, de manera que gairebé no haurà de tocar-se el codi.
Sobre 5)
Tant la iniciativa Open Social com la Open Knowledge Initiative (en aquesta segona hi estic molt involucrat) defineixen maneres per a fer el login massa complexes per al que volem. Si el que vols és una API, pots escollir qualsevol d'aquestes dos: milers de mètodes, centenars de classes... Son perfectes sobre el paper, però tingues en compte que jo mateix codirigeixo el projecte del primer d'implementació de l'API de OKI en el món. Et puc garantir que no serà útil per al que tu has de fer.
L'inici i el manteniment de la sessió contra PHP es farà invocant un mètode estàtic d'una classe PHP. Aquest mètode pot implementar la interfície que vulguis (de fet, aquesta classe és la "teva" API). El codi d'aquest mètode podrà ser des de la connexió a un servidor LDAP a una query contra un MySQL o a un Oracle Virtual Private Database.
El més senzill és fer-ho en PHP, iniciar la sessió amb session_start() i comprovar que a la base de dades existeixi el username i que l'md5 del seu password coincideixi amb el que està enmagatzemat a la taula d'usuaris de la BD. Per finalitzar la sessió bastaria un session_destroy. Username i md5 del password poden anar en base64 en el mateix XML, per exemple. Aquesta solució és plenament funcional, terriblement potent i tremendament simple.
De totes maneres, en la propera reunió de PFC parlarem dels patrons de disseny a aplicar a la part de servidor.
Diga-li al teu amic que no tot són APIs a la vida. Les seves reflexions són molt interessants i poden haver-te facilitat el veure més clar el projecte, però no és bo creure's el que diuen els standards o els frameworks. Les APIs, els frameworks... només són eines, no dogmes de fe, i les eines s'han de fer servir quan calen i només quan calen.
Igual que no faries servir una clau anglesa per a cargolar el cargol de les patilles d'unes ulleres, no faras servir Hibernate si no et cal. A més, aquests frameworks van a modes, mentre que les bones idees perduren per sempre.
Sincerament, crec que el teu amic hauria de veure més coses i no només Java. S'han de conèixer més d'un llenguatge per a poder comparar :)
Toma parrafada.
Salut!
Publicar un comentario