Ron
-
Posts
376 -
Joined
-
Last visited
-
Days Won
31
Content Type
Profiles
Forums
Events
Posts posted by Ron
-
-
There is no built-in event providing info on transfer, as far as I know.
Normally the progress is shown on the user side.
I suppose you could use a separate indy http server to serve the file
and get transfer info that way.
Or you may just show a form to the user, counting down to some
approximate download time, to show some movement
-
You can log in the user automatically, so you only need to know which user,
and then pick up whatever he did last, and show the form where he left.
So how to ID the user? A cookie with fast expiration is probably the best
option. Public IP may be shared, but if combined with local client IP, within a short
timeframe, it should be pretty secure. E.g. WebRTC JS API and the ICE protocol
to get local LAN IP. It could be DHCP but within a short timeframe it should be
ok for less critical apps.
Last option to ID the user would be to log all mouse movements and key presses
and create a personal time/motion profile of the user, and check for matching patterns
-
"now I'm in love with javaScript."
JS is like a cute and clever woman - you never know exactly what she's gonna do,
and how she's gonna do it, and if she will even do it, and if so, when she's gonna do it
Any coder cannot help but being infatuated by such an interesting partner...
-
2
-
-
The only thing most people would need, is the DB and maybe DB access components
if you cannot use what is in Delphi already.
I use MySQL and microOLAP db access components, and it was not expensive.
You may need some non-visual components or code, depending on whatever you make.
There are of course many Sencha third-party components that you may get to work
with Unigui. For instance, there is a calendar component, but I made my own based on JS code.
It all depends on how complex your app is, and what it connects to.
But for most typical projects, you only need the DB and db access, and then you're good to go.
-
procedure TMainForm.unimdateTimePickerChange(Sender: TObject);
begin
showMessage(dateTostr(unimdateTimePicker.Date));
end; -
Sure, you can use url parameters to display any form you like
as the app loads. If you use the standard login form, you can
just autologin users going to other forms, to a fixed userid for
differentiation, or you can make you own login routine.
-
Guys, we are on the same page on this. I too came in early with Unigui after having tried another delphiweb solution
where the support just faded away and the company turned their focus on another app, and there were many of us
who paid about $600 for that, and basically went away empty-handed.
Now I clearly saw - immediately - that things were totally different with Unigui. The thing is that here we have one
guy who is 100% dedicated - he takes this personally - and judging from his efforts so far, he will not give this up easily.
A good teams is great, but it always depends on a very good leader, and in this case I say we have it. That is why
I can put all my business in his hands, and I am sure that if Farshad has to get out somehow, he will give us the source code.
The framework is brilliant, we can leverage the power of both Delphi and ExtJS to the max, interfacing with ISAPI,
I almost don't know what more to ask for, except Websockets. The source code will come eventually, as we turn 1.0,
or at least that is what I expect. Please correct me if I am wrong.
Sure, things have dragged out, but things have also been pretty stable for a long time, and we can all appreciate
the complexity of these things. To have a guy willing to dedicate such a big part of his life to make sense of this
technological mess we are in, and give us the opportunity to use our favorite tools to get things done, is just great.
So when I ask about the company, it is not because I do not trust Farshad or his ability to complete this project - far from it.
I just want to know if things are even better than what I already assume. We have one super-dedicated guy, and this
is his baby, and that's great - but what more do we have? I am not in the loop to make an educated guess - I am just curious.
-
1
-
-
You don't need to handle anything in the loginform, as the mainmodule beforelogin event
is called first, so you handle it there, and set "handled" as you please.
You can pick up the url params in mainmodule, and handle it all in the beforelogin event.
That is the logic.
As for posting to a session to affect its state, there is obviously a security question
if you are going to let outside processes affect a running session. The session is
and must be tightly linked to the client all the way, and I would assume you could
get concurrency issues too if you start opening up the session for outsiders
without some extra stuff handling that. Data is all about consistency, and thus security.
-
Hello,
uniGUI is developed by FMSoft which is a micro-ISV located in Ankara / Turkey.
I am the lead developer of the project. Project is alive for past 7 years. We will continue developing and improving uniGUI for a foreseeable future.
We've just turned the corner by releasing uniGUI RC (Release Candidate) which shows it is no longer beta!
Hopefully, the non-RC release will be available soon too.
uniGUI is not related to Intraweb and it doesn't need it. uniGUI has its own internal webserver and component system.
Thank you for your interest in uniGUI.
Hi Farshad, could you please elaborate on the staff of FMSoft, how many developers you
have in the company, and to which degree the future development of Unigui is dependent on you
personally being active and available for the company.
Also I realize that there is in effect a wider network of developers coming into play
as a result of this forum, and can you please elaborate on how many of these people
you consider to be part of a stable support group that may be around in the future,
to eventually carry the development forward if FMSoft somehow gets incapacitated.
Opening up the complete source code will of course provide added security for
future development, and should be done as the beta is over with, and I guess that is also
the plan, so that is great. All these things are about security and should be considered.
-
I guess it will nearly always be preferable to stay in the session, as the other
process may halt and thus fail to trigger the new session start.
If you know for sure that you will get a new session start no matter what,
that approach may be more stable as there is less complexity.
The critical thing is the time spent, and I guess up to a minute should be ok with
the current session, but what about let's say half an hour? - that is too much of course,
to keep it alive on a timer, so then a new session is probably better.
-
You can pass a parameter in the URL, but it will create a new session,
so you have to handle the login, catch the correct user ID if necessary,
and process the request. I assume there is a login.
So first you construct a response url, where you put in a key that you
generate, and you store this key in the db linked to the user, and give
it a timeout datetime, and you pass this url to the shopping cart as
the response url they shall trigger at payment accept.
And in mainModule, beforelogin, you catch the url param with the
key, check it in the db, and if it matches you process the request,
and put up whatever response, logging the user in at the same time,
pulling up whatever order was just accepted. All you need is a key
that you pass and get back again and check, using the url as storage.
You put a timeout on the whole process, like 30-60 seconds,
and in that window you accept the key and process the req,
and if not you don't log the user in, but put up another message.
-
Here is some code in that area:
http://disprein.blogspot.no/2009/04/creating-win32-security-descriptor-with.html
-
In my opinion you can use users with different rights. After they login - transfer them to different forms
Right, you can use the peerIP, the local time of day, the local outside temperature, client browser properties/client opsys...in short whatever,
to create different responses from the server upon login or after login. That is the nature of a server - you decide what is to
be served, on which conditions. If you have a predetermined group of people, user access may be the easiest way. If there is no
user login, other available client data may be used to create different server responses.
-
Sure, you can use url params, like domain.com?page=master
and domain.com?page=worker, both served by a single server,
standalone or not, and you will see different forms if you set it up
like so, when loading the app.
If you want to avoid url params, I think you need a webserver, and
then you can redirect domain.com/master to a DLL
and in the redirect you can insert the url params.
If you totally want to avoid url params, you can use a webserver
and redirect to two different instances of the same DLL, using the
url to determine category, or a local file being loaded at mainmodule create.
By "sending commands", you do not really send commands to a page
but to the server, and if you create a server-side routine that checks
a db for changes, you can then present that on the other page.
The app can know which category it is in (master/worker) and query
only the commands intended for it.
For more direct browser client-client communication, you have to use
websocket clients in each web client, and set up an extra websocket
server to connect the clients.
-
Just discovered how to do it on apache, just use DirectoryIndex
<Directory "C:/mydlldir/">
Options FollowSymLinks ExecCGI
AllowOverride None
Order allow,deny
Allow from all
DirectoryIndex mydll.dll
</Directory>
Alias /myapp "C:/mydlldir"Navigating to http://myserver.com/myapp will load the dll, hiding the extension in the url.
You should be able to set the directory index file specifically in IIS too, of course.
-
1
-
-
Well, I was able to setup a system according to this idea mentioned above,
and test it on a live server with apache, but the problem was the loading time
of a new standalone server: 15 seconds from login vs 5 secs using a single dll.
I used a login.dll running under apache, which spawned a new standalone unigui server
for each logged in user: it executed the exe on a new port for each user, by running the
apache on a user with network resources access privileges. So that worked.
Uplading a new version of the standalone exe worked fine too, with setting the
firewall rule for the file, opening up for all ports.
But due to the extended loading time, 15 secs vs 5 secs when using a dll, this will
probably not work so well.
But I kind of liked the idea of separating the login from the main application,
as you then get very fast loading time of that small login app, and it provides
a small waiting spot for the user while redirecting to the new active updated app,
informing of what is happening.
I found a working compromise: use one login app, and two main apps,
where one is the active at any time.
At update, one dll is updated and set to active, and the main apps
notice that, and inform the user of the option to update.
At update, the user is kicked back to the login app, but I have an extra
session layer with the session key in the url param, and this gets picked
up by the login app which sends the user over to the new active mainapp dll.
One could use cookies instead of such an extra session layer.
This way users may switch to the new active app individually, and I have
separated the login from the main app.
From login to main app load, I give the main app 5 seconds to confirm
the new session key in the db, and it is valid for 12 hours, from that public IP.
So this is possible, with three DLL's, one for login/session control, and
two main apps where one stays active at any time, making the other available
for updating.
Maybe this could be done even without a login app, and use the webserver
to direct the user to the active app, using a url rewrite based on some data
from the file system or the db, setting the url of the active app.
-
"...in this case you need to sepcify it manually..."
Why do you then need to specify it ? Please clarify.
"...retrieved from request header parameters 'Referer'..."
How early, in the startup process, can this be done, and how?
-
There are a number of ways to get a file to unigui, first some acting as server.
1. Use the built-in indy HTTP server, and the uniServerModule events OnHTTPCommand and
OnHTTPDocument. Then you have to encode the file before you send it. There is no point in
setting up an extra HTTP server, as unigui contains one already.
2. Use an indy TCP server in the uniServerModule, and a TCPClient in the VCL app.
This is by far the easiest and most straightforward way, use TCPClient.IOHandler.writeFile
on the client side and ReadStream on the server side.
3. Use an FTP server in the uniServerModule, and an FTP client on the VCL side.
FTP is a bit more complex than TCP, but also provides more options.
4. Use an SMTP server and send the file as a mail attachment, or any other protocol.
Of all these protocols, TCP is the easiest one to set up for simple text/binary file transfer.
Of course the TCP server would have to run on a different port than the built-in unigui indy webserver.
Historically, I think it is safe to say that FTP and TCP have been the primary protocols
for binary internet transfer, especially on upload, with HTTP Post gradually taking a bigger
part of that pie as working encoding solutions have been worked out.
The reason for the increased use of HTTP Post for binary transfer, is the ability to then
use the webserver which is already there, not having to think about opening extra ports
in the firewalls for another listening server, and so on.
The challenge with HTTP Post file transfer is the encoding of the data, and also to some
degree the transfer process. With TCP or FTP you do not need to think very much about that.
If anyone has tested and working code for HTTP Post of binary files using indy, please post it here.
You could also get a file to unigui server, with unigui acting as client. Just send a HTTP
command (i.e. including the link) to trigger the unigui server to initiate the download of the file,
which it then does, moves it to someplace and then generates a download link.
This of course assumes the file is already available online.
-
I've made a test project according to the idea I mentioned above, download
at http://s000.tinyupload.com/index.php?file_id=26843721044701981814
It contains two projects, one loginapp and one mainapp.
At login, a new standalone server will be created, on a new port.
The mainapp standalone exe's are located under the loginapp folder,
in separate dirs, with the dir name indicating the version.
At update, control will return to the login app, and the running process will
be killed and a new standalone server process created, on the new
exe available in the new dir.
The drawback is that the main apps will all be standalone servers, but there
will be one for each user, so there should really not be any resource issues
as long as the server box keeps up.
Hard to say what is more stable: x threads in an Apache/IIS container
or running them directly under the operating system as separate processes
like this.
But here you can at least get individual updates, where anyone can update
when they want to on an individual basis - think I will try it out.
-
Let's say I have an Apache or IIS main server, where the user logs in.
At login I then execute a standalone server at a different port, serving
the main application - one such standalone for each new user.
As an upgrade is available by timer->db/filecheck, the user is served a notice in
the app, having the option to upgrade, which then kills the standalone
server, routes the user back to the main login app which keeps the
session, and creates a new standalone server based on new exe,
again serving the secondary app to the user.
-
Problem is that with a single server, you cannot discriminate between sessions/users,
and either keep'em all or kill'em all.
Waiting for all to be inactive may take forever.
So you then basically need one server for each user, and then you can upgrade only
those who are not active.
You could setup a system which spawns a new server for each user, and then another
update system to kill the right servers for upgrade at first inactive - but that is quite complex.
The goal is to upgrade without losing the session and thus disconnecting the user.
What about using two applications, where one is a shell application which is not
updated, but only keeps the session - and then another main application which
gets updated?
That may be possible, two DLL's served by one server, using the ISAPI loader to update
only one of them, and as the second app session terminates the user is directed to
the first app, which then loads the second app after update...as it also loads the second
app after login, and the user is all the time having the shell app session alive.
But to do upgrades on an individual basis, requires separate servers. It is the nature
of the issue, as individual and group are two separate domains, and cannot be joined.
-
I guess it all depends on the nature of the signal that you are monitoring,
i.e. the rate of change, the predictability of that range or the function of change.
If it is RPM, which changes constantly like every second, you might as well
use a timer, as you will be sending/getting data every second anyway.
No point in making it complex if you always know when the data comes.
However, if the data changes now and then, and it is a point to keep
the client/server communication to a minimum, and critical to get the
update when it comes, then a more complex solution might be in place.
There is nothing wrong with a timer in itself, and you can log it, and
set up other systems to monitor it and whatever. Your box is run by
a Ghz timer, and it works great, so timers are super basic in computer systems.
Without them, like in the form of crystals, we would have nothing.
Timers are like frequencies, or patterns, symphonies of energy...
they are the building blocks of the entire universe etc etc...don't fool with timers!
-
You are long polling the unigui server through the client instance,
which has the db connection and thus access to the fresh data,
or another webserver that you set up somewhere, that has
access to the data you need.
For instance, I have a cash drawer and receipt printer installed locally
with the customer, and when the cash drawer is opened, I make an http
call to the local windows service controlling the cash drawer, which is
running an http webserver, and within that service I do not respond
to the http call until the drawer is closed.
On the unigui end I pick up the fresh db results as the http blocking
long polling call finishes, because I then know the service app has
saved the cash drawer state to the db.
From a uniHTMLFrame I assume you can do some of the same stuff,
make a long polling ajax call somehow, to the unigui server through the
client instance.
I also have the option of a timer, instead of long polling, to get the
cash drawer status, and the last option is no checking of status.
But new regulations now demand that no POS transactions may be
done while the drawer is opened, so that state must be logged.
-
This kind of functionality - resources - is not something I typically find
in the calendars/schedulers available, and only in the more advanced
implementations, like ExtCalendar and some others.
I too speculated about this option in calendar panel, but as far as
I know, it did not exist. But maybe this have changed, not sure, but
the thing is not heavily documentet from the ExtJS side.
But I needed so many different options, that it would probably have
been a bigger nightmare to use the calendar panel, than to write
my own calendar.
I too would like a very advanced, customizable day/month calendar
made purely in ExtJS, with push functionality, rooms, graphics and
all the bells and whistles. If I had a free year or two, I'd like to make
that, but I'd have to learn ExtJS well first, and that takes another year...
Keep user session data
in General
Posted
Intraweb is obviously doing some state saving in the background then,
to a session state table, linking that post to a cookie.
But if you do auto-saving of form data, silently, 5 secs after no data change,
and link this to the user, and then to a cookie, you will get the same functionality.
If your fields are db-aware with a live query, it is just a timer that runs Post,
and the cookie can ID both the user and the form last used, taking him back.
You can also use a URL param to preserve a session during a refresh, since
the URL is read at servermodule.create, but to get that unique URL param you
may have to do some trick, like either having two apps, or getting the
isapi server to produce a random URL param that can function as a session ID.
But a session state component seems like a good idea. To get around the
need for informing about cookies, maybe a URL param would solve the issue.
Goodbye to clean uRL's then...