Re: The Revenge of the Geeks

From: BGB <>
Date: Sat, 26 Jan 2013 13:22:11 -0600
Message-ID: <ke1afi$lij$>

On 1/26/2013 5:26 AM, Arved Sandstrom wrote:

> On 01/25/2013 12:31 AM, BGB wrote:
>> On 1/24/2013 9:15 PM, Arne Vajh°j wrote:
>>> On 1/24/2013 10:10 PM, BGB wrote:
>>>> On 1/24/2013 4:58 PM, Arne Vajh°j wrote:
>>>>> On 1/24/2013 5:10 PM, BGB wrote:
>>>>>> On 1/24/2013 10:06 AM, Arne Vajh°j wrote:
>>>>>>> On 1/23/2013 11:47 PM, BGB wrote:
>>>>>>>> but, in any case, with the other languages there are a wide
>>>>>>>> range of
>>>>>>>> libraries available, many under fairly open licenses (like MIT or
>>>>>>>> BSD),
>>>>>>>> and there is a lot more GPL stuff available,
>>>>>>> In the EE space you would need to look at CORBA or DCOM.
>>>>>>> You would prefer Java EE believe me.
>>>>>>> :-)
>>>>>> errm, so you can't just copy all the files over to ones' servers?
>>>>>> and/or
>>>>>> recompile the code for ones' servers?...
>>>>> The coding model in Java EE is definitely more modern than that
>>>>> of CORBA and DCOM.
>>>> I didn't mean like CORBA or DCOM, but probably directly copying over
>>>> program binaries (DLLs or SOs and precompiled binaries and similar),
>>>> and
>>>> probably using traditional compilation and linking.
>>> You lost me.
>>> How to get the same type of services as Java EE provides is related
>>> to copying binaries how?
>> I may be missing something here...

> [ SNIP ]

> Step back for a moment. We are talking servers and their clients. On the
> server side you start out with a vanilla install on a physical box or
> VM: might be Apache httpd or IIS, might be Tomcat or WebLogic, might be
> ActiveMQ or WebSphere MQ, might be Active Directory or OpenLDAP, might
> be H2 or DB2 or Oracle or SQL get the idea.

> The server install sets up directories, executables (services or tools),
> libraries (DLLs, *.so's, Java JARs etc), baseline config information,
> and so forth. At this stage of the game you may or may not have a
> useable, albeit uninteresting, server. Further configuration is often
> required to make it useable (e.g. the directory servers).

> After all this it's probably still uninteresting. You need to write
> server applications, and you need to develop clients (often, not
> always). For a web server or app server you write your ASP.NET MVC or
> Java EE or PHP apps. Those apps will use libraries that came with the
> baseline server, but you may use other libraries that are either shared
> on the server or bundled up/deployed with the specific server app.

> In some cases the actual server that you write your own server
> applications on is *itself* a server application sitting on a server.
> For example, ECM systems like FileNet P8 or Alfresco are actually
> humongo web apps (more or less) on app servers like Tomcat or WebSphere
> (plus using database servers and maybe directory servers) that you can
> the drop your own apps onto. IBM Cognos is itself a Java EE app.

> On the client side, if it's a web app you've got a browser; there's not
> anything left to do. But possibly your server application is providing
> SOAP or REST web services - in that case you will be writing client
> code. If CORBA, you're generating and writing client code. If WebSphere
> MQ you're often writing client code.

> These clients also need libraries, whether JARs or native shared/static
> libraries. Frequently there are client installers that supply all of this.

> You do not generally copy things in the manner you describe. Server
> installs can be pretty complicated - if you need a new server on a new
> box then you work through the approved install process...just like you'd
> do with an .EXE or .MSI installer for a standalone app on Windows.

> In fact, with few exceptions, *removing* a server and all its artifacts
> can be pretty complicated and tedious too.

> As to deployment of server and client apps, these often have a
> deployable form. In Java EE these are JARs or WARs or EARs. Other
> systems (ESBs, BPM systems, certain forms of IIS app deployment etc)
> often have a publishing/deployment procedure that involves ZIPs of
> directory/file structures. The IDE that you develop in, more often than
> not, already knows how to create the proper deployment packages.

> As for Java SE versus Java EE, the latter is the former plus reams of
> extra libraries. The latter also encompasses the contracts for anyone
> who is going to provide a Java EE-compliant application server.


well, ok, I run a web-server mostly running Apache.

apart from MediaWiki, most of the content thus far is static pages and files.

so, not really some huge/complicated web-app thing, nor does it interact with any other servers (it contents are pretty much all self-contained, ...).

I had generally imagined web-servers mostly like they were file-servers, but with the plus-side of having a defined browser-level interface, and the ability to use scripts or binaries to generate contents.

for a client-side app (probably a traditional desktop-style application), it would use an HTTP server mostly like a file-server for retrieving updated resources and similar. a CGI script could mostly exist to provide a manifest and so the client app can know if/what files to download.

dunno about an app working in a browser, I haven't personally really looked much into this. the one thing I had noted which I felt might make this worthwhile was "Google Native Client", but given it is Chrome-only at this point, this is a drawback (better if Firefox supported it, but the FF people apparently oppose it).

Adobe Flash sometimes seemed like a possible option, but isn't particularly compelling, and the development environment apparently costs money.

but, generally, I more prefer the desktop application experience... Received on Sat Jan 26 2013 - 20:22:11 CET

Original text of this message