¿Por qué no te cambias a un lenguaje "moderno"?

[[newtron]]

Compañeros...

En estas fechas estoy intentando resolver un tema de firmas para poder enviar facturas electrónicas a la plataforma "face" mediante webservice, la verdad es que sin mucho resultado.

Mirando por la red veo que las herramientas de microsoft tienen de forma nativa componentes para resolver estos temas en los que yo estoy bastante pegado, me acuerdo de un conocido que desarrolla con .NET, lo llamo para preguntarle por el asunto y me dice que no me puede ayudar pero que si, que con .NET se pueden manejar firmas y certificados de forma nativa y me dice el jodío....¿por qué no te cambias ya a un lenguaje moderno?

[Casimiro Notevi]

No estoy al tanto del tema de esos certificados, pero sobre lo que dice esa persona:

https://jonlennartaasenden.wordpress...-about-delphi/
https://translate.google.com/transla...bout-delphi%2F

Es lo que tiene la ignorancia.
Párrafo del enlace anterior:

C# es mejor que Delphi?

En realidad, no lo es. Lo que hoy se conoce como .net, desde su lenguaje intermedio CIL hasta el caché de ensamblaje global es Delphi. Sí, leíste bien que toda la familia de productos .net es Delphi. Fue descrito en los servidores de noticias de Borland años antes de que apareciera mágicamente como el producto estrella de Microsoft.

Anders Hejlsberg creó y creó prototipos de estas tecnologías mientras trabajaba en Borland. Y, de hecho, el padre de C# y todo .net no es otro que el padre de Delphi.

La ley es muy simple: cada nivel solo puede emitir complejidad hacia arriba.
Entonces el ensamblador se usa para producir C y pascal.
C y pascal se usa para producir C++ y Object Pascal.
C++ y Object Pascal se usan para producir cada otra pieza de tecnología que se da por sentada.

[[Al González]]

Empezado por newtron

Compañeros...

En estas fechas estoy intentando resolver un tema de firmas para poder enviar facturas electrónicas a la plataforma "face" mediante webservice, la verdad es que sin mucho resultado.

Mirando por la red veo que las herramientas de microsoft tienen de forma nativa componentes para resolver estos temas en los que yo estoy bastante pegado, me acuerdo de un conocido que desarrolla con .NET, lo llamo para preguntarle por el asunto y me dice que no me puede ayudar pero que si, que con .NET se pueden manejar firmas y certificados de forma nativa y me dice el jodío....¿por qué no te cambias ya a un lenguaje moderno?

Tristemente, una de las asignaturas pendientes de Embarcadero (dado lo escandaloso de sus precios de licenciamiento) es integrar de manera nativa algo tan necesario hoy en día como la firma XML. Hace un par de meses di por hecho que Berlin ya venía preparado para estas cosas, pero mi gran sorpresa fue notar que la RTL no trae nada realmente útil relacionado con certificados X.509 y vainas similares del cifrado moderno. Lo cual, por otro lado, algunos fabricantes de componentes Delphi (grandes y pequeños) siguen manteniendo en la obscuridad, al mismo tiempo que venden soluciones parciales a este problema al mayor precio posible.

¿O de verdad hay algo que no dependa de OpenSSL o .NET, código fuente realmente moderno (no en C), humanamente escrito en archivos .pas u otro lenguaje moderno como Delphi, para estos menesteres?

[fduenas]

Hola, Ya existen soluciones para trabajar con certificados e implementados.

Bambucode ha desarrollado una librería pra trabajar con XML, leer un certificado y sellarlo.
Se usa el DLL del openSSL. Y usa webservices para el timbrado con la dependencia fiscal, en le caso de méxico con el SAT.

hxxps://github.com/bambucode/tfacturaelectronica

Puedes tomar el ejemplo y aplicarlo tu mismo para eso.

Tambien puedes checar esta librería TurboPower Lockbox 3 (es una versión completamente nueva, muy avanzada y diferente de TP lockbox 2).

hxxp://lockbox.seanbdurkin.id.au/HomePage
hxxps://github.com/SeanBDurkin/tplockbox

Ese ya implementa muchas soluciones que se necesitan para los certificados, si les gusta el proyecto hagan una donación para que se pueda seguir trabajando con la librería.

NO veo el problema de usar Librerías externas a delphi, .NET tambien lo hace, así que eso de que .NET ya trae funciones es es algo relativo, con .NET siempre vas a depender que tu Framework pueda ser ejecutado en el ambiente en el que trabaje la máquina. Con las DLL de openssl eso no es necesario.

[[newtron]]

Empezado por fduenas

Hola, Ya existen soluciones para trabajar con certificados e implementados.

Bambucode ha desarrollado una librería pra trabajar con XML, leer un certificado y sellarlo.
Se usa el DLL del openSSL. Y usa webservices para el timbrado con la dependencia fiscal, en le caso de méxico con el SAT.

hxxps://github.com/bambucode/tfacturaelectronica

Puedes tomar el ejemplo y aplicarlo tu mismo para eso.

Tambien puedes checar esta librería TurboPower Lockbox 3 (es una versión completamente nueva, muy avanzada y diferente de TP lockbox 2).

hxxp://lockbox.seanbdurkin.id.au/HomePage
hxxps://github.com/SeanBDurkin/tplockbox

Ese ya implementa muchas soluciones que se necesitan para los certificados, si les gusta el proyecto hagan una donación para que se pueda seguir trabajando con la librería.

NO veo el problema de usar Librerías externas a delphi, .NET tambien lo hace, así que eso de que .NET ya trae funciones es es algo relativo, con .NET siempre vas a depender que tu Framework pueda ser ejecutado en el ambiente en el que trabaje la máquina. Con las DLL de openssl eso no es necesario.

Gracias por la info.