Jump to content

Roadmap for uniGUI 1.0.0


Guest

Recommended Posts

Message from: "schweppes"

 

Farshad,=20

 

you have my and other users support and wish you all the best.

 

Great product and awesome support.

 

 

"Farshad Mohajeri" wrote in message =

news:9iMYd$JmLHA.2080@anaxagvs227...

=

http://www.unigui.com/index.php?option=3Dcom_jaggyblog&task=3Dviewpost&id=

=3D111&Itemid=3D115

 

 

 

__________ Information from ESET NOD32 Antivirus, version of virus =

signature database 5693 (20101210) __________

 

The message was checked by ESET NOD32 Antivirus.

 

http://www.eset.com

 

 

 

__________ Information from ESET NOD32 Antivirus, version of virus signatur=

e database 5693 (20101210) __________

 

The message was checked by ESET NOD32 Antivirus.

 

http://www.eset.com

 

 

 

Link to comment
Share on other sites

Message from: "Junior/RO"

 

Farshad Mohajeri escreveu:

 

> http://www.unigui.com/index.php?option=com_jaggyblog&task=viewpost&id=111&Itemid=115

 

Good work.

 

I still have this opinion about documentation: start a wiki and let the users to write it. You will be the moderator. And I think you will be positively surprised.

 

--

Que é essa vida se, com tanto a fazer, não temos tempo para parar e ver?

.

 

Link to comment
Share on other sites

Message from: "Harry Rogers"

 

Hi Farshad

 

Looks very impressive. Nice job, still filled with admiration for this

project, it is awesome !

 

Is there currently any means to 'shadow' a session or can you for see a

mechanism to facilitate this ?

 

Best regards

 

Harry Rogers

"Farshad Mohajeri" wrote in message

news:9iMYd$JmLHA.2080@anaxagvs227...

http://www.unigui.com/index.php?option=com_jaggyblog&task=viewpost&id=111&Itemid=115

 

 

.

 

Link to comment
Share on other sites

Message from: "Farshad Mohajeri"

 

"Junior/RO" wrote in message

news:$GCkF$MmLHA.2080@anaxagvs227...

> Farshad Mohajeri escreveu:

>

>> http://www.unigui.com/index.php?option=com_jaggyblog&task=viewpost&id=111&Itemid=115

>

> Good work.

>

> I still have this opinion about documentation: start a wiki and let the

> users to write it. You will be the moderator. And I think you will be

> positively surprised.

>

 

Wiki is a nice idea. It can be useful. I'll think about it.

 

 

.

 

Link to comment
Share on other sites

Message from: "Farshad Mohajeri"

 

"Harry Rogers" wrote in message

news:zFvZjPSmLHA.232@anaxagvs227...

> Hi Farshad

>

> Looks very impressive. Nice job, still filled with admiration for this

> project, it is awesome !

>

 

Thanks

 

> Is there currently any means to 'shadow' a session or can you for see a

> mechanism to facilitate this ?

>

 

Shadowing a session? You mean two browser windows accessing same web

session?

 

 

.

 

Link to comment
Share on other sites

Message from: "Harry Rogers"

 

>> Is there currently any means to 'shadow' a session or can you for see a

>> mechanism to facilitate this ?

>>

>

> Shadowing a session? You mean two browser windows accessing same web

> session?

Yes the idea would be to allow one session to access to another - for

training / support

 

 

.

 

Link to comment
Share on other sites

Message from: "Junior/RO"

 

Harry Rogers escreveu:

 

> Yes the idea would be to allow one session to access to another - for training / support

 

This will be nice to have.

 

--

Que é essa vida se, com tanto a fazer, não temos tempo para parar e ver?

.

 

Link to comment
Share on other sites

Message from: "Farshad Mohajeri"

 

"Harry Rogers" wrote in message

news:rvLcP%23WmLHA.2080@anaxagvs227...

>

>>> Is there currently any means to 'shadow' a session or can you for see a

>>> mechanism to facilitate this ?

>>>

>>

>> Shadowing a session? You mean two browser windows accessing same web

>> session?

> Yes the idea would be to allow one session to access to another - for

> training / support

>

 

Transferring an existing state from a session to a new blank session is

nearly impossible. You must reconstruct a cloned "state" from info available

in an existing "server session" and remote state info in an exsiting

"browser session".

 

 

.

 

Link to comment
Share on other sites

Message from: "Harry Rogers"

 

Farshad Mohajeri wrote:

 

>

> "Harry Rogers" wrote in message

> news:rvLcP%23WmLHA.2080@anaxagvs227...

> >

> > > > Is there currently any means to 'shadow' a session or can you

> > > > for see a mechanism to facilitate this ?

> > > >

> > >

> > > Shadowing a session? You mean two browser windows accessing same

> > > web session?

> > Yes the idea would be to allow one session to access to another -

> > for training / support

> >

>

> Transferring an existing state from a session to a new blank session

> is nearly impossible. You must reconstruct a cloned "state" from info

> available in an existing "server session" and remote state info in an

> exsiting "browser session".

 

I was thinking the same.

 

What about this as a concept ..... ?

The server has a property to echo all traffic for a session to a 'file'

(in memory of physical) When a session is started there is a switch

goverened by Client IP address or Authentication that enables/disables

this echo.

 

[- There would probably be quite a hit on performance if enabled on

multiple sessions and written to a serverside physical file...]

 

To shadow a session 'Simply' play back this file.

 

I guess this would require a new component on the client side that

could be 'loaded' with the browsers recorded events keystrokes/clicks

(i.e. all data sent from the mirrored client to the server) and have

methods for Play/stop etc to send the data back to the server. Along

with a protocol....

 

An 'authorized shadow session' requests to have its event/keystroke

component populated from a recording.

 

The server sends the first chunk of data from the recording to the

'authorized shadow session' (i.e. the client doing the mirroring) which

gets us to the initial state. (e.g a sending a login screen to the

browser) Plus a 'tag' to say play the next 'frame' from your

event/keystoke component please.

 

The event/Keystroke component responds (followed by it's tag set to say

'Can we have the next server side data from the recoring please?'

 

 

server then sends the next... etc etc

 

 

- Probably deeply flawed !! - (Seems plausible to my little brain)

 

 

I know you have plenty else to be getting on with, so maybe a 'back

burner' for the future ?

 

 

All the best

 

Harry

 

--

 

.

 

Link to comment
Share on other sites

Message from: "Farshad Mohajeri"

 

"Harry Rogers" wrote in message

news:F%23HxA3rmLHA.2316@anaxagvs227...

> Farshad Mohajeri wrote:

>

>>

>> "Harry Rogers" wrote in message

>> news:rvLcP%23WmLHA.2080@anaxagvs227...

>> >

>> > > > Is there currently any means to 'shadow' a session or can you

>> > > > for see a mechanism to facilitate this ?

>> > > >

>> > >

>> > > Shadowing a session? You mean two browser windows accessing same

>> > > web session?

>> > Yes the idea would be to allow one session to access to another -

>> > for training / support

>> >

>>

>> Transferring an existing state from a session to a new blank session

>> is nearly impossible. You must reconstruct a cloned "state" from info

>> available in an existing "server session" and remote state info in an

>> exsiting "browser session".

>

> I was thinking the same.

>

> What about this as a concept ..... ?

> The server has a property to echo all traffic for a session to a 'file'

> (in memory of physical) When a session is started there is a switch

> goverened by Client IP address or Authentication that enables/disables

> this echo.

>

> [- There would probably be quite a hit on performance if enabled on

> multiple sessions and written to a serverside physical file...]

>

> To shadow a session 'Simply' play back this file.

>

> I guess this would require a new component on the client side that

> could be 'loaded' with the browsers recorded events keystrokes/clicks

> (i.e. all data sent from the mirrored client to the server) and have

> methods for Play/stop etc to send the data back to the server. Along

> with a protocol....

>

> An 'authorized shadow session' requests to have its event/keystroke

> component populated from a recording.

>

> The server sends the first chunk of data from the recording to the

> 'authorized shadow session' (i.e. the client doing the mirroring) which

> gets us to the initial state. (e.g a sending a login screen to the

> browser) Plus a 'tag' to say play the next 'frame' from your

> event/keystoke component please.

>

> The event/Keystroke component responds (followed by it's tag set to say

> 'Can we have the next server side data from the recoring please?'

>

>

> server then sends the next... etc etc

>

>

> - Probably deeply flawed !! - (Seems plausible to my little brain)

>

>

> I know you have plenty else to be getting on with, so maybe a 'back

> burner' for the future ?

>

 

Looks very interesting, but also seems very complicated to implemenet. I may

do some experiments with a very simple session with an empty Form to see to

what level it is achievable.

 

 

.

 

Link to comment
Share on other sites

Message from: "Harry Rogers"

 

"Farshad Mohajeri" wrote in message

news:4msCup5mLHA.2080@anaxagvs227...

>

> "Harry Rogers" wrote in message

> news:F%23HxA3rmLHA.2316@anaxagvs227...

>> Farshad Mohajeri wrote:

>>

>>>

>>> "Harry Rogers" wrote in message

>>> news:rvLcP%23WmLHA.2080@anaxagvs227...

>>> >

>>> > > > Is there currently any means to 'shadow' a session or can you

>>> > > > for see a mechanism to facilitate this ?

>>> > > >

>>> > >

>>> > > Shadowing a session? You mean two browser windows accessing same

>>> > > web session?

>>> > Yes the idea would be to allow one session to access to another -

>>> > for training / support

>>> >

>>>

>>> Transferring an existing state from a session to a new blank session

>>> is nearly impossible. You must reconstruct a cloned "state" from info

>>> available in an existing "server session" and remote state info in an

>>> exsiting "browser session".

>>

>> I was thinking the same.

>>

>> What about this as a concept ..... ?

>> The server has a property to echo all traffic for a session to a 'file'

>> (in memory of physical) When a session is started there is a switch

>> goverened by Client IP address or Authentication that enables/disables

>> this echo.

>>

>> [- There would probably be quite a hit on performance if enabled on

>> multiple sessions and written to a serverside physical file...]

>>

>> To shadow a session 'Simply' play back this file.

>>

>> I guess this would require a new component on the client side that

>> could be 'loaded' with the browsers recorded events keystrokes/clicks

>> (i.e. all data sent from the mirrored client to the server) and have

>> methods for Play/stop etc to send the data back to the server. Along

>> with a protocol....

>>

>> An 'authorized shadow session' requests to have its event/keystroke

>> component populated from a recording.

>>

>> The server sends the first chunk of data from the recording to the

>> 'authorized shadow session' (i.e. the client doing the mirroring) which

>> gets us to the initial state. (e.g a sending a login screen to the

>> browser) Plus a 'tag' to say play the next 'frame' from your

>> event/keystoke component please.

>>

>> The event/Keystroke component responds (followed by it's tag set to say

>> 'Can we have the next server side data from the recoring please?'

>>

>>

>> server then sends the next... etc etc

>>

>>

>> - Probably deeply flawed !! - (Seems plausible to my little brain)

>>

>>

>> I know you have plenty else to be getting on with, so maybe a 'back

>> burner' for the future ?

>>

>

> Looks very interesting, but also seems very complicated to implemenet. I

> may do some experiments with a very simple session with an empty Form to

> see to what level it is achievable.

>

>

That's great Farshad, thanks

 

 

 

.

 

Link to comment
Share on other sites

  • 1 month later...

Message from: "Sergio"

 

Farshad Mohajeri wrote:

 

>

> "Harry Rogers" wrote in message

> news:F%23HxA3rmLHA.2316@anaxagvs227...

> > Farshad Mohajeri wrote:

> >

> > >

> >>"Harry Rogers" wrote in message

> > > news:rvLcP%23WmLHA.2080@anaxagvs227...

> > > >

> >>> > > Is there currently any means to 'shadow' a session or can you

> >>> > > for see a mechanism to facilitate this ?

> >>> > >

> >>> >

> >>> > Shadowing a session? You mean two browser windows accessing same

> >>> > web session?

> >>> Yes the idea would be to allow one session to access to another -

> >>> for training / support

> > > >

> > >

> > > Transferring an existing state from a session to a new blank

> > > session is nearly impossible. You must reconstruct a cloned

> > > "state" from info available in an existing "server session" and

> > > remote state info in an exsiting "browser session".

> >

> > I was thinking the same.

> >

> > What about this as a concept ..... ?

> > The server has a property to echo all traffic for a session to a

> > 'file' (in memory of physical) When a session is started there is a

> > switch goverened by Client IP address or Authentication that

> > enables/disables this echo.

> >

> > [- There would probably be quite a hit on performance if enabled on

> > multiple sessions and written to a serverside physical file...]

> >

> >To shadow a session 'Simply' play back this file.

> >

> > I guess this would require a new component on the client side that

> > could be 'loaded' with the browsers recorded events

> > keystrokes/clicks (i.e. all data sent from the mirrored client to

> > the server) and have methods for Play/stop etc to send the data

> > back to the server. Along with a protocol....

> >

> > An 'authorized shadow session' requests to have its event/keystroke

> > component populated from a recording.

> >

> > The server sends the first chunk of data from the recording to the

> > 'authorized shadow session' (i.e. the client doing the mirroring)

> > which gets us to the initial state. (e.g a sending a login screen

> > to the browser) Plus a 'tag' to say play the next 'frame' from

> > your event/keystoke component please.

> >

> > The event/Keystroke component responds (followed by it's tag set to

> > say 'Can we have the next server side data from the recoring

> > please?'

> >

> >

> > server then sends the next... etc etc

> >

> >

> > - Probably deeply flawed !! - (Seems plausible to my little brain)

> >

> >

> > I know you have plenty else to be getting on with, so maybe a 'back

> > burner' for the future ?

> >

>

> Looks very interesting, but also seems very complicated to

> implemenet. I may do some experiments with a very simple session with

> an empty Form to see to what level it is achievable.

 

I find it very dificult to get both sessions on sync.

 

If I click on a "upload file", and you get a copy of those clicks an

"play them" on your session, it will fail because you don't have this

file on your PC... you don't only have to mimmic all the state of one

session om the other, but also some more things that are out of reach

for unigui.

 

A more simple big problem: One session deletes a record, the other

session try to mimmic, but if fails as the record to be deleted has

been already deleted!

 

It is like been driving 50 meters behind your wife's car, and try to

follow her by repeating axactly the same actions she does... but your

car is different, the trafic if different... you can't crash into the

saem truck!

.

 

Link to comment
Share on other sites

Message from: "Harry Rogers"

 

Sergio wrote:

 

> Farshad Mohajeri wrote:

>

> >

> > "Harry Rogers" wrote in message

> > news:F%23HxA3rmLHA.2316@anaxagvs227...

> > > Farshad Mohajeri wrote:

> > >

> > > >

> > >>"Harry Rogers" wrote in message

> > > > news:rvLcP%23WmLHA.2080@anaxagvs227...

> > > > >

> > >>> > > Is there currently any means to 'shadow' a session or can

> > you >>> > > for see a mechanism to facilitate this ?

> > >>> > >

> > >>> >

> > >>> > Shadowing a session? You mean two browser windows accessing

> > same >>> > web session?

> > >>> Yes the idea would be to allow one session to access to another

> > - >>> for training / support

> > > > >

> > > >

> > > > Transferring an existing state from a session to a new blank

> > > > session is nearly impossible. You must reconstruct a cloned

> > > > "state" from info available in an existing "server session" and

> > > > remote state info in an exsiting "browser session".

> > >

> > > I was thinking the same.

> > >

> > > What about this as a concept ..... ?

> > > The server has a property to echo all traffic for a session to a

> > > 'file' (in memory of physical) When a session is started there is

> > > a switch goverened by Client IP address or Authentication that

> > > enables/disables this echo.

> > >

> > > [- There would probably be quite a hit on performance if enabled

> > > on multiple sessions and written to a serverside physical file...]

> > >

> > >To shadow a session 'Simply' play back this file.

> > >

> > > I guess this would require a new component on the client side that

> > > could be 'loaded' with the browsers recorded events

> > > keystrokes/clicks (i.e. all data sent from the mirrored client to

> > > the server) and have methods for Play/stop etc to send the data

> > > back to the server. Along with a protocol....

> > >

> > > An 'authorized shadow session' requests to have its

> > > event/keystroke component populated from a recording.

> > >

> > > The server sends the first chunk of data from the recording to the

> > > 'authorized shadow session' (i.e. the client doing the mirroring)

> > > which gets us to the initial state. (e.g a sending a login screen

> > > to the browser) Plus a 'tag' to say play the next 'frame' from

> > > your event/keystoke component please.

> > >

> > > The event/Keystroke component responds (followed by it's tag set

> > > to say 'Can we have the next server side data from the recoring

> > > please?'

> > >

> > >

> > > server then sends the next... etc etc

> > >

> > >

> > > - Probably deeply flawed !! - (Seems plausible to my little brain)

> > >

> > >

> > > I know you have plenty else to be getting on with, so maybe a

> > > 'back burner' for the future ?

> > >

> >

> > Looks very interesting, but also seems very complicated to

> > implemenet. I may do some experiments with a very simple session

> > with an empty Form to see to what level it is achievable.

>

> I find it very dificult to get both sessions on sync.

>

> If I click on a "upload file", and you get a copy of those clicks an

> "play them" on your session, it will fail because you don't have this

> file on your PC... you don't only have to mimmic all the state of one

> session om the other, but also some more things that are out of reach

> for unigui.

>

> A more simple big problem: One session deletes a record, the other

> session try to mimmic, but if fails as the record to be deleted has

> been already deleted!

>

> It is like been driving 50 meters behind your wife's car, and try to

> follow her by repeating axactly the same actions she does... but your

> car is different, the trafic if different... you can't crash into the

> saem truck!

 

- I was thinking of recording and playing back the

 

'visual interface drawing traffic'

 

rather than the application logic.

 

It was only some thoughts out loud really to provoke a bit of a

discussion - some form of shadowing would undoubtidly be useful - but

it may not be practical with this paradigm.

 

Cheers

 

--

 

.

 

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...