harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <j...@kewlstuff.co.za>
Subject Re: Visualizing JreLite
Date Wed, 05 Mar 2008 18:28:36 GMT

----- Original Message ----- 
From: "Stepan Mishura" <stepan.mishura@gmail.com>
To: <dev@harmony.apache.org>
Sent: Wednesday, March 05, 2008 7:28 AM
Subject: Re: Visualizing JreLite


> On 3/5/08, Johnny Kewl <john@kewlstuff.co.za> wrote:
>>
>> This is how I see it happening... I always talk from the point of view of
>> Windows users... they must be able to use it.
>>
>> BOOTSTRAP
>> ==========
>>
>> There is a small bootstrap program it is called JRELite... its a native
>> app probaby 80k
>>
>> When this is installed on a system it does a file association with
>> "JreLite"
>>
>> THE JAVA APPLICATION
>> ===================
>>
>> To use this system a user will reaname their execuatable jar from
>> MyApp.jar
>> to
>> MyApp.JreLite
>>
>> The above is all a user needs to know about and its how a user see's it.
>>
>> SCENARIO
>> =========
>>
>> A programmer put their JreLite application on a web page, or emails it to
>> a freind or its on a flash stick...
>> ... anything
>>
>> The user clicks on it...
>> The system effectively runs JRELite MyApp.JreLite
>>
>>
>> INITIAL HIT
>> ========
>>
>> The bootstrap see's there is no Java on tha machine... it gets the
>> JVMLite Engine...
>> Approx 3 meg HIT...
>>
>>
>
> Do you expect any security issues here? How you are going to verify
> that dynamically downloaded bits are 'original' bits (i.e. not
> cracked) ?

Software does not have to be signed... its not like an applet, its no more
dangerous than a user deciding to download Harmony.
ie its a conscious click... besides, its someone elses application, the JRE
cant do anything about that.
If the primary supplier of the application wants to protect the user, they
will make a SSL web page for instance.

As for the JVMLite pulling components from the server... the bootstrap can
give the user the choice of SSL, or not.
It must be a choice because if the server is used internal to a company,
they dont need SSL.

There will be certified (well known servers), these are precoded into
the JRELite bootstrap....
If a third party wants to add a well known server, they need to ask.... (now
my
imagination is taking off ha ha) google can allocate
a specific site (I have a feeling they will be interested ;) for the JreLite
bootstrap... if someone wants to add a server, they have to
ask IGI (IntelGoogleIbm) for permission for it to be added.... this means
that if a server fails, the JreLiteBoot or JVM Resolver
can retry a few servers before giving up....
(now my imagination is flying) ... the servers contain PURE JAVA classes...
BUT, if an organization wants to add more API
to the server... say the ability for a programmer to program 911 calls into
their programs... then IGI has to approve them
.... an so the world is safe ;)

The application itself comes from whoever makes it and is placed on any
medium... so what the servers are really serving
is API, and so this must be safe.

Uses I think must not be charged to use the servers, thats stupid... but
there can be premuim services that come into
play thru special API.... if you click, gimme a pitza in an app... you
expect to pay ;)

The signed sofware CA model is old and boring, please no... these servers
fund themselves by selling
API.... :)
And then lets get the IT biz back to normal human biz models... they make
extra money
threw cool derivative services... that come from the API.
Programmers can add a emergency help number to their code, if the user
clicks it, a gorgeous
blonde arrives at the door ;) etc etc

.... and I'm sending IGI my consulting bill ;)


> Thanks,
> Stepan.
>
>> STARTUP
>> ========
>>
>> The Bootstrap place JVMLite in its special folder location...
>> Start... JVMLite -jar MyApp.JreLite
>>
>>
>> RUNNING BOOTSTRAP
>> ==================
>>
>> The application starts and it needs a swing... the JVM's resolver can
>> determine this...
>> It loads it.
>>
>> So the thing to really understand is that the application starts almost
>> immediately but its "still"
>> loading from the remote server, AS THE USER IS USING IT....
>>
>> It feels like Java started in 20 seconds and remember this is only the
>> first (one time hit)...
>> After that programs start "instantly"
>>
>> Also think about this.... if a user never goes to a part of the
>> application that is not used... that never has to be loaded.
>>
>> Bottom Line
>> =========
>> If we can strip the JRE down to somewhere around 3 megs.... make the
>> classes and fonts late binding... and put them on a deliver server.
>> JRELite exists...
>>
>> The JVMLite work... is mainly in bridging the resolver with the ability
>> to pull the require component down from the server.
>> Where ever that font engine is hiding... it too has to bridged with the
>> ability to pull a font down.
>>
>> The rest of the work... is in making the downloads fine grained... you
>> let the JVM pull the classes it needs... NOT the whole Jar.
>> So those Jars live on the server as a file structure...
>>
>> If the font needed is Gothic A, and that needs a Unicode DLL.... ONLY
>> that moves over the wire...
>>
>> Yes... oh boy... they all packed into humongeuos file now.... that has to
>> be fine grained on the server.
>>
>> This works so well... you going to be shocked at how efficient Java
>> becomes ;)
>>
>> Harmony is not far from this already.... the packaging just has to
>> change.
>>
>> For now... just that needs to be done... complex optimizations can come
>> later.
>>
>> ... I think ;)
>>
>


Mime
View raw message