[ previous ] [ next ] [ threads ]
 
 From:  "Imran K" <gururug at gmail dot com>
 To:  "Marcel Wiget" <mwiget at mac dot com>, radiussupport at lrcommunications dot net
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Re: [m0n0wall] Ticket Printer Project
 Date:  Thu, 20 Dec 2007 23:02:56 +1100
Food for thought........
__________________________________________________________________________________

Thinking laterally, to minimise output issues, probraby not going to get you
out of your seat but.............

How about using a large address range. Auth credentials are tied to specific
IP's which are accounted to certain download limits or access time.

Start of each day / other, owner prints single sheet / clicks auto generate
new accounts and 100-1000 etc. random accounts are spat out onto a piece of
paper.

Some comes and says "i want 2 hours access" then you give them the two hour
credentials for the day. Someone says "i don't know how much time i need but
can i have 100MB?"

What are the requirements here???

a) minimal admin interaction
b) minimal hardware fiddling
c) account security (non-abuse)

I mean, if are going to go down the print on demand model, surely we will
have to define 2-6 printer models that are up to the job and supported.

re: the flash applet, nice idea, harder to maintain if primary developer
busy / drifts / other

__________________________________________________________________________________

i would be going the ip printer route, more flexibility in positioning and
drivers if you can use ipp / generic ip driver. yes, stand alone mini-print
server may be required.

to make this scalable,  the way i see it is the mono handles;

-interface
-printing

-interface ties in to local db and remote radius server / local captive
hooks (why not the option for either)
-printer ties into generic ipp driver or limited devices

as the ticketing module is php and perhaps leverages sql for storage, there
is no reason why it cannot be moved to backend / middle tier servers on
larger deployments.

hardest bit about coding this would be the captive hooks and the accounting
if it need to be done on mono.

anyway, back to the day job :)


















On Dec 20, 2007 10:09 PM, Marcel Wiget <mwiget at mac dot com> wrote:

> Alex,
>
> instead of printing the vouchers individually "on the spot" when the
> customer is asking for it, we're looking more into an easier way to have
> the
> store/shop printing the vouchers in advance and simply hand them out on
> request. That's where the Flex2 idea kicks in, where the hotspot operator
> can "mass produce" vouchers.
>
> This would also take away all those nasty issues with printer not
> working/out of paper and also of not having to add yet another electrical
> device to each point of sale.
>
> The only downside I see so far with creating vouchers in advance is that
> they might run out of vouchers and need to get to a web based terminal to
> create a new batch.
>
> Marcel
>
> On Dec 19, 2007 11:03 PM, Alex M <radiussupport at lrcommunications dot net>
> wrote:
>
> > Well still POS is whole different story. Its like separate project. I
> just
> > wanna hace something like DLink solution. I guess I just get my dlink
> > hotspot and do the video so everu one get my point
> >
> >
> > -----Original Message-----
> > From: Jakob Strebel [mailto:jakob at teamstrebel dot ch]
> > Sent: Wednesday, December 19, 2007 1:35 PM
> > To: Monowall Support List
> > Subject: Re: [m0n0wall] Ticket Printer Project
> >
> > Hello list readers,
> >
> > what about the following idea.
> >
> > We could write the voucher Printig code in Flex2 / Actionscript-3.
> > (Flex2 runs in the Flash player as a virtual machine in all the popular
> > web browsers and is platform OS independent)
> > This code could be hosted in the M0n0 or stored on a external webserver.
> >
> > Here are some advantages:
> > - The complexity of the M0n0wall would not increase.
> > (we all like m0n0wall because it is kept easy and simple)
> > This Flash application would talk to the stable voucher application done
> > by Marcel Wiget.
> > - This solution would use standard printer drivers.
> > - Widely lower cost USB Label Printer could also be used.
> > - Labels could also be printed on a standard Laser Printer. This would
> > allow to print adds or useful stuff on the voucher.
> > - optional flexibility, executing printing of vouchers trough the
> > landing page of the captive portal. For identification, customer name
> > and voucher code could be printed on the Voucher.(possible misuse could
> > be  prevented by checking the MAC address of the guest PC who requests a
> > voucher)
> > - optional flexibility doing a web based self service terminal.
> > - Some EU countries dictate by law the registration of user name.
> > - By doing this the developement cycle can be independent of the release
> > of m0n0
> > - Landing page branding could easily achieved.
> >
> > I do not have any intention to interrupt the current discussion. I
> > thought it would be worthwhile to look at alternatives to implement a
> > flexible voucher printing solution.
> >
> > Best regards
> > Jakob
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> >
>