Hi All.
Probably this isn't the right place to ask for this, but since i've seen some "i wish scalix had" messages here, here is mine:
Wil Scalix ever allow the user to select a default delivery location for mail other than the Imailbox itself and to a pst instead, with outlook connector?
Best Regards,
Bruno Guereiro
Scalix 11.3 is on the way ...
Moderators: ScalixSupport, admin
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
Hm... questions about software and software products should probably avoid the word "ever" as much as responses to those questions should avoid the word "never"!
with this being said, at least if we continue on our current track, this is one not to be looked at anytime soon, and here's why.
1. you're talking about Outlook functionality. This is not fully under our control, so it is certainly not easy, because we don't control the codepath where this happens. Sometimes there are APIs for things (for this one, there is none), sometimes it is possible to tweak and hack Outlook a little bit from the inside to make things happen and our people are experts at doing that - according to their feedback, this is at the very least not an easy nut to crack. Is it impossible? Maybe, at least without Microsoft's help. Now - what makes it sometimes hard to give responses like this when it comes to Outlook and functionality, at some point, someone will say - "but you can do this with Exchange". Now, that answer won't help, because although in priciple everything goes via MAPI, Microsoft has chosen to do a couple of things inside Outlook that they can do, because they control both the client and the server and have the full source code available and/or not to document this as part of the MAPI interface. This is one example.
2. If you ask me, this is really the wrong thing to do.... couple reasons.... first, Scalix for me is all about choice, especially and certainly so on the client side - i.e. you can access your mailbox with Outlook, SWA, Evolution, Kontact, IMAP and, with 11.3, CalDAV. And more to come I believe. Now, if you consider this, I think it's not really good to store any kind of data that such a system uses in a proprietary format that is only accessible to one of the clients, and that's what the PST is, effectively. Even in a pretty one-client-on-the-desktop environment using Outlook, you would want to be able to access your mailbox using the web client, when you're on the road. Second, you most likely want - or you're even legally required - to backup and archive your email data. With it being in PSTs you have a much larger overhead than if you keep it on the server. When you keep it local on the client, you go into all the nightmares of windows client backup, if you put it on a fileserver you at least lose the single-copy properties of messages and your data store becomes larger and the question is, if you have to offer the amount of server-side diskspace anyway, why wouldn't you keep it in your email system.
So - unless I'm missing something, from any kind of strategic perspective, this is not highly desirable functioanlity and the only reason I can currently see to look at it at all is the (un-)unsual "Exchange can do it" answer, however, not sure if that's the right and most successful approach.
Guess, this is open for comment by anyone.
Florian.
with this being said, at least if we continue on our current track, this is one not to be looked at anytime soon, and here's why.
1. you're talking about Outlook functionality. This is not fully under our control, so it is certainly not easy, because we don't control the codepath where this happens. Sometimes there are APIs for things (for this one, there is none), sometimes it is possible to tweak and hack Outlook a little bit from the inside to make things happen and our people are experts at doing that - according to their feedback, this is at the very least not an easy nut to crack. Is it impossible? Maybe, at least without Microsoft's help. Now - what makes it sometimes hard to give responses like this when it comes to Outlook and functionality, at some point, someone will say - "but you can do this with Exchange". Now, that answer won't help, because although in priciple everything goes via MAPI, Microsoft has chosen to do a couple of things inside Outlook that they can do, because they control both the client and the server and have the full source code available and/or not to document this as part of the MAPI interface. This is one example.
2. If you ask me, this is really the wrong thing to do.... couple reasons.... first, Scalix for me is all about choice, especially and certainly so on the client side - i.e. you can access your mailbox with Outlook, SWA, Evolution, Kontact, IMAP and, with 11.3, CalDAV. And more to come I believe. Now, if you consider this, I think it's not really good to store any kind of data that such a system uses in a proprietary format that is only accessible to one of the clients, and that's what the PST is, effectively. Even in a pretty one-client-on-the-desktop environment using Outlook, you would want to be able to access your mailbox using the web client, when you're on the road. Second, you most likely want - or you're even legally required - to backup and archive your email data. With it being in PSTs you have a much larger overhead than if you keep it on the server. When you keep it local on the client, you go into all the nightmares of windows client backup, if you put it on a fileserver you at least lose the single-copy properties of messages and your data store becomes larger and the question is, if you have to offer the amount of server-side diskspace anyway, why wouldn't you keep it in your email system.
So - unless I'm missing something, from any kind of strategic perspective, this is not highly desirable functioanlity and the only reason I can currently see to look at it at all is the (un-)unsual "Exchange can do it" answer, however, not sure if that's the right and most successful approach.
Guess, this is open for comment by anyone.
Florian.
Florian von Kurnatowski, Die Harder!
-
bguerreiro
- Posts: 91
- Joined: Wed Mar 08, 2006 11:28 am
Hi again Florian.
Ever and never advice noted :-)
I agree partally with the easyness and availability everywhere of the mailbox content. In facto that's one of the benefits I comment to our users when explaining them the <irony> loss of functionality </irony>.
On the other hand, our company has very liberal approach to what users can receive by email, so mailboxes tend to get really large, which fills up with the incoming/outgoing messages.
I know one can use the rules to move the messages around, but in the case of the sent messages this rules only apply to new messages, so that means that new sent messages get stored in one place, and replies/forwards get stores in another place.
But I'll guess I'll stick with trying to educate our users, which for now has worked. Just hope I don't hit some "unmovable obstacle".
Onde again, thanks for your time.
Best Regards.
Bruno Guerreiro,
P.S.About the SWA slowliness, shall I ping support for the patch, or can you manageto sent it to me?
Ever and never advice noted :-)
I agree partally with the easyness and availability everywhere of the mailbox content. In facto that's one of the benefits I comment to our users when explaining them the <irony> loss of functionality </irony>.
On the other hand, our company has very liberal approach to what users can receive by email, so mailboxes tend to get really large, which fills up with the incoming/outgoing messages.
I know one can use the rules to move the messages around, but in the case of the sent messages this rules only apply to new messages, so that means that new sent messages get stored in one place, and replies/forwards get stores in another place.
But I'll guess I'll stick with trying to educate our users, which for now has worked. Just hope I don't hit some "unmovable obstacle".
Onde again, thanks for your time.
Best Regards.
Bruno Guerreiro,
P.S.About the SWA slowliness, shall I ping support for the patch, or can you manageto sent it to me?
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
Hi Bruno,
thanks for your message. From my perspective, now we're talking - because what I'd like to talk about under topic of if we're going to do something is rather problems that we can solve instead of specific functionality or even their implementations we should discuss.
The problem at hand is a very real one - mailboxes get larger and larger. Part of that is just the fact that email is taking over a larger percentage of communications, both in business and private lifes. However, another fact is that information is stored inside mailboxes that could better be put somewhere else - attachments. Attachmens are large files, they, IMHO, belong on fileservers, and, in some cases, even better, versioned file stores like Enterprise Content Management systems. One of the worst uses of email is two people working together on a document and bouncing it back and forth between them, creating numerous versions of it in the message store, resulting in problems with backup time, store management, client performance and other unfortunate stuff.
The solution here, as I see it, is not found by archiving out old mechanisms into proprietary, hard-to-manage local stores across hundreds or thousands of client computers, but, cleverly recognizing the extra payload and automatically externalizing it to an appropriate place.
Now, when you ask if Scalix is planning to address this issue, although I don't want to and can go into details, I'll dare saying that the answer is yes, the timeframe is the coming 12 months and the goal is to really move us forward on this problem - however, it won't happen by backing up into PST hell. Stay tuned!
I'll send you separate download information for the 11.2.0.58 patch.
Cheers,
Florian.
thanks for your message. From my perspective, now we're talking - because what I'd like to talk about under topic of if we're going to do something is rather problems that we can solve instead of specific functionality or even their implementations we should discuss.
The problem at hand is a very real one - mailboxes get larger and larger. Part of that is just the fact that email is taking over a larger percentage of communications, both in business and private lifes. However, another fact is that information is stored inside mailboxes that could better be put somewhere else - attachments. Attachmens are large files, they, IMHO, belong on fileservers, and, in some cases, even better, versioned file stores like Enterprise Content Management systems. One of the worst uses of email is two people working together on a document and bouncing it back and forth between them, creating numerous versions of it in the message store, resulting in problems with backup time, store management, client performance and other unfortunate stuff.
The solution here, as I see it, is not found by archiving out old mechanisms into proprietary, hard-to-manage local stores across hundreds or thousands of client computers, but, cleverly recognizing the extra payload and automatically externalizing it to an appropriate place.
Now, when you ask if Scalix is planning to address this issue, although I don't want to and can go into details, I'll dare saying that the answer is yes, the timeframe is the coming 12 months and the goal is to really move us forward on this problem - however, it won't happen by backing up into PST hell. Stay tuned!
I'll send you separate download information for the 11.2.0.58 patch.
Cheers,
Florian.
Florian von Kurnatowski, Die Harder!
-
kanderson
For a reseller, This is a positive change.
My worst experiences with Scalix are ones where someone has installed Community, done their migration, hits a serious issue, and THEN calls me, hoping for free support for a free product. (This is a bigger issue with Ubuntu than Scalix, but it happens for both...)
At that point, I know nothing about a person's network, it's already broken, and I can feel the pressure of them getting helled at in the background while I need to ignore my current customers to help this person out. And I may or may not ever hear from them again.
Most will pay for support, because they just need things fixed. NOW. But I feel like I'm blackmailing them telling them I can't do free support, and they feel like I'm taking advantage of the situation.
This is a worst case scenario.
The best case scenario is that a customer calls me in advance of deployment. We can plan out a transition, in the end, I know the person I'm working with, and they know me. I understand their network, I often even know who the main users are, and stuff like that. We start into it with good will, and a clear understanding of everyone's goals. And this is free, because my payment is embedded in the cost of purchasing the software.
Making the point of entry lower means that I'll see more best case, and fewer worst case. And that's a good thing.
For those of you complaining that this is about money for Scalix (or the reseller) think about this. I'll spend a few hours of time, for free, with a client who's buying a $600 software package. I'm not getting rich on that, and clearly, neither is Scalix.
Much like Florian, most of the resellers have been in the Scalix fold for a while, and we believe in the product. I have differences with Scalix (Florian) on some decisions when I think the best thing for the client is something different than what he thinks is best. This is not one of those times, however. This is decision is a good one for Scalix.
Kev.
My worst experiences with Scalix are ones where someone has installed Community, done their migration, hits a serious issue, and THEN calls me, hoping for free support for a free product. (This is a bigger issue with Ubuntu than Scalix, but it happens for both...)
At that point, I know nothing about a person's network, it's already broken, and I can feel the pressure of them getting helled at in the background while I need to ignore my current customers to help this person out. And I may or may not ever hear from them again.
Most will pay for support, because they just need things fixed. NOW. But I feel like I'm blackmailing them telling them I can't do free support, and they feel like I'm taking advantage of the situation.
This is a worst case scenario.
The best case scenario is that a customer calls me in advance of deployment. We can plan out a transition, in the end, I know the person I'm working with, and they know me. I understand their network, I often even know who the main users are, and stuff like that. We start into it with good will, and a clear understanding of everyone's goals. And this is free, because my payment is embedded in the cost of purchasing the software.
Making the point of entry lower means that I'll see more best case, and fewer worst case. And that's a good thing.
For those of you complaining that this is about money for Scalix (or the reseller) think about this. I'll spend a few hours of time, for free, with a client who's buying a $600 software package. I'm not getting rich on that, and clearly, neither is Scalix.
Much like Florian, most of the resellers have been in the Scalix fold for a while, and we believe in the product. I have differences with Scalix (Florian) on some decisions when I think the best thing for the client is something different than what he thinks is best. This is not one of those times, however. This is decision is a good one for Scalix.
Kev.
-
kanderson
Wishlist.
Since this is also a wishlist thread. I'll reitterate what everyone already knows.
Over the air Activesync. Glad that it's coming, the sooner it's here the better. This is huge.
No Connector. This is also huge. I'll make a suggestion here. I SUSPECT that Scalix will eventually support both connector and connectorless connections. Can you please give those of us on here a heads up so that we can use the connectorless connection a bit in advance of everyone else. We can help dogfood it, and we'd really appreciate it.
BES server connections. Notify works. It's not a bad solution. But BES is well known and covers the devices that Activesync doesn't. I hope (and assume) this will work in step with a connectorless client. That's awesome.
PLEASE drop support for Fedora and OpenSuSE. The upgrade path sucks, and too many people are taking it to production with no idea of the consequences. Please drop it. Please. We have (brutal) support for Debian. This should be the same thing. Have the installer pop up a warning saying this is an unsupported platform, and continuing is not recommended, but then let people continue. Same type of warning as <512 Megs of RAM.
Speaking of RAM, Change that 512 to 1024. Postgres and Tomcat need more now, up the minimum. Consiter 2048. I'd way rather see a "Your server does not meet the recommended RAM requirements for this new release, it will still function as expected, but performance will be greatly improved with the addition of more RAM." for >512 & <2048.
Upgrades should not clobber settings. In particular, SWA login logos tat are replaced should not be lost.
For people asking about Spam/AV and Backups. I'd recommend talking to your reseller. All of these are easily set up, and this is where resellers prove their value, both to Scalix and to the end users.
Kev.
Since this is also a wishlist thread. I'll reitterate what everyone already knows.
Over the air Activesync. Glad that it's coming, the sooner it's here the better. This is huge.
No Connector. This is also huge. I'll make a suggestion here. I SUSPECT that Scalix will eventually support both connector and connectorless connections. Can you please give those of us on here a heads up so that we can use the connectorless connection a bit in advance of everyone else. We can help dogfood it, and we'd really appreciate it.
BES server connections. Notify works. It's not a bad solution. But BES is well known and covers the devices that Activesync doesn't. I hope (and assume) this will work in step with a connectorless client. That's awesome.
PLEASE drop support for Fedora and OpenSuSE. The upgrade path sucks, and too many people are taking it to production with no idea of the consequences. Please drop it. Please. We have (brutal) support for Debian. This should be the same thing. Have the installer pop up a warning saying this is an unsupported platform, and continuing is not recommended, but then let people continue. Same type of warning as <512 Megs of RAM.
Speaking of RAM, Change that 512 to 1024. Postgres and Tomcat need more now, up the minimum. Consiter 2048. I'd way rather see a "Your server does not meet the recommended RAM requirements for this new release, it will still function as expected, but performance will be greatly improved with the addition of more RAM." for >512 & <2048.
Upgrades should not clobber settings. In particular, SWA login logos tat are replaced should not be lost.
For people asking about Spam/AV and Backups. I'd recommend talking to your reseller. All of these are easily set up, and this is where resellers prove their value, both to Scalix and to the end users.
Kev.
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
-
bbryan
- Posts: 43
- Joined: Thu Aug 23, 2007 5:47 pm
- Location: California
florian wrote:bbryan wrote:I second what charon said, we would like to see more support for wireless synchronization.
Bbryan,
are you using Blackberry only or also any other devices where Active Sync support will help you?
Florian.
We have a few MS devices, but for the most part we are using blackberries.
Thanks.
Ben
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
Right, so at this time the only solution for you is NotifyLink and possibly waiting until we can really get going with a BES-integrated solution together with RIM, which we are looking into and working on, however, it's unlikely to happen until 2H/2008. Funambol's Blackberry support would not make true Blackberry users happy. Active Sync won't help.
Cheers,
Florian.
Cheers,
Florian.
Florian von Kurnatowski, Die Harder!
-
PaulHerron
- Posts: 21
- Joined: Fri May 05, 2006 11:48 am
- Location: Washington, DC
Florian wrote:So I currently see SyncML mostly as a solution for contact synchronisation and some calendaring on low-end phone devices like the RAZR or similar that don't have feature-rich sync clients or OSs. Those are not the devices our users and customers typically want to use with Scalix.
I see you're point here, Florian, particularly with regard to Scalix's own interest in a stable and clean synchronization. Many thanks to PhilJohn for his work on a SyncML connector where none existed but, I don't think anyone would argue that the connector doesn't come without its share of troubleshooting and caveatting.
Florian wrote:As for App2App synchronisation, like between Scalix and Sugar, I don't think putting a sync server in the middle will actually be a good idea here - in that area our strategy is rather based on open-standards based online access to data through WebDAV, CalDAV or web services APIs - after all, servers don't really need to sync with other servers as they are both thought to be continously available and synchronisation has it's biggest benefits in mobile/offline situations. Scalix 11.3 ships with extensive DAV access and we'll continue to work in making this offering broader for truely open server2server and client2server APIs.
What you argue here makes sense too. However, don't forget that some folks are looking to implement funambol not just as a solution for synchronizing Scalix to their mobile devices but to also synchronize other applications with that mobile device. One synchronization server to maintain can be less hassle than multiples.
In my case, I have field staff using time tracker software on their Windows Mobile devices to track their billable hours. Using funambol OTA sync will allow us to get time data into our accounting package (QuickBooks) faster -- better info., better management decisions. In the future, I hope to add synchronization with parts of our knowledge management portal/extranet to the list of OTA services available.
I had thought that I would base everything off just one sync server but, based on Florian's argument, I guess there's no harm in running OTA ActiveSync for Scalix, and funambol for time sheets and knowledge management/extranet, on the same mobile device. Right, Florian?
-Paul
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
PaulHerron wrote:I see you're point here, Florian, particularly with regard to Scalix's own interest in a stable and clean synchronization. Many thanks to PhilJohn for his work on a SyncML connector where none existed but, I don't think anyone would argue that the connector doesn't come without its share of troubleshooting and caveatting.
Right - although I want to make it clear the my fundamental criticism of SyncML as a solution here has nothing to do with this or any other specific connector - one could certainly develop a Scalix-Funambol connector with full coverage - the problem are the devices on the "other" side, and not the ones where you intall something, but the ones where you can't install something that comes from the sync vendor, i.e. the ones coming with very loosely defined SyncML clients of their own, i.e. as part of the phone OS.
What you argue here makes sense too. However, don't forget that some folks are looking to implement funambol not just as a solution for synchronizing Scalix to their mobile devices but to also synchronize other applications with that mobile device. One synchronization server to maintain can be less hassle than multiples.
In my case, I have field staff using time tracker software on their Windows Mobile devices to track their billable hours. Using funambol OTA sync will allow us to get time data into our accounting package (QuickBooks) faster -- better info., better management decisions. In the future, I hope to add synchronization with parts of our knowledge management portal/extranet to the list of OTA services available.
OK, you have a point here - and that might be a reason to reconsider, i.e. if it is found that many of our customers and prospects are already using a particular sync solution, e.g. Funambol, as their main hub betweem many applications and devices.
I had thought that I would base everything off just one sync server but, based on Florian's argument, I guess there's no harm in running OTA ActiveSync for Scalix, and funambol for time sheets and knowledge management/extranet, on the same mobile device. Right, Florian?
Dangerous area to make a statement in unless fully tested, but I would say that theoretically and fundamentally there should be no harm to do that as long as the sync application on the device acts with the native databases on the device. This is the case for Windows Mobile sync solutions as MSFT provides proper device APIs, this is not totally true of Blackberry devices, which are too closed to allow full device access to the sync vendor so many of the sync vendors actually use their own databases and even email and other clients on the device. In those cases, the two solutions would probably still coexist, but not integrate and handle the same data.
Florian.
Florian von Kurnatowski, Die Harder!
-
Kris
- Posts: 247
- Joined: Tue Jul 04, 2006 7:24 am
florian wrote:The solution here, as I see it, is not found by archiving out old mechanisms into proprietary, hard-to-manage local stores across hundreds or thousands of client computers, but, cleverly recognizing the extra payload and automatically externalizing it to an appropriate place.
Now, when you ask if Scalix is planning to address this issue, although I don't want to and can go into details, I'll dare saying that the answer is yes, the timeframe is the coming 12 months and the goal is to really move us forward on this problem - however, it won't happen by backing up into PST hell. Stay tuned!
Sounds very interesting, can't you give even a liiiiiitle more detals?
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
-
steves
- Posts: 23
- Joined: Mon Mar 20, 2006 10:02 pm
licensing
Hi Guys,
As a consultant I think you have a pretty good product and we are using it with clients that have linux servers. Functionality wise I do not think it is comparable to MS Exchange but it is getting there. Mainly to "peripherals" support.
We have a few clients that are sitting on the 10-15 premium user seat level and we have been waiting for Outlook 2007 support for almost a year...
You introduced Outlook 2007 support but it looks like only on 11.3, hmmm...
It looks like those client have no option at all but to buy the 20 License package. And guess what you can't buy new PCs with Office 2003, so what does that mean? ...
Unfortunately this reminds me some Competitor's tactics.
I think it will be wise you reconsider your licensing model and make thinks clear in advance....
Thank you,
Steve
As a consultant I think you have a pretty good product and we are using it with clients that have linux servers. Functionality wise I do not think it is comparable to MS Exchange but it is getting there. Mainly to "peripherals" support.
We have a few clients that are sitting on the 10-15 premium user seat level and we have been waiting for Outlook 2007 support for almost a year...
You introduced Outlook 2007 support but it looks like only on 11.3, hmmm...
It looks like those client have no option at all but to buy the 20 License package. And guess what you can't buy new PCs with Office 2003, so what does that mean? ...
Unfortunately this reminds me some Competitor's tactics.
I think it will be wise you reconsider your licensing model and make thinks clear in advance....
Thank you,
Steve
-
florian
- Scalix
- Posts: 3852
- Joined: Fri Dec 24, 2004 8:16 am
- Location: Frankfurt, Germany
- Contact:
Hi
<quote>You introduced Outlook 2007 support but it looks like only on 11.3, hmmm...</quote>
<quote>Unfortunately this reminds me some Competitor's tactics. </quote>
I can assure you, spilling insider's information, that with the exception of the fact that both changes need a delivery vehicle, i.e. "a" release, there is no "tactics" behind them happening in parallel. It's simply a matter of having a number of balls in the air, moving forward fast, having to get a couple of jobs done. Nothing else.
<quote>It looks like those client have no option at all but to buy the 20 License package. And guess what you can't buy new PCs with Office 2003, so what does that mean? ...</quote>
I agree that this link could be seen as unfortunate by some. However, on the other hand, given what these new PCs produce in cost for your 10+ user business (i.e. think total operational IT cost in such organisation), the price you'd need to pay for the Scalix product if this was really what you need would be so little compared to other components that I find that quite easy to justify.
The fact that Microsoft opts to no longer ship an older version of their product, resulting in quite broad and fundamental change in presumably quite unrelated areas of their customers infrastructure highlights the risks of lock-in, stickiness and cross-selling associated with the use of a single vendor's products, especially when that vendor is not committed to open standards and interfaces.
IMHO, this truely highlights the strong need to consider client-side alternatives as well and we'll continue to help keeping that door open now and going forward.
Florian.
<quote>You introduced Outlook 2007 support but it looks like only on 11.3, hmmm...</quote>
<quote>Unfortunately this reminds me some Competitor's tactics. </quote>
I can assure you, spilling insider's information, that with the exception of the fact that both changes need a delivery vehicle, i.e. "a" release, there is no "tactics" behind them happening in parallel. It's simply a matter of having a number of balls in the air, moving forward fast, having to get a couple of jobs done. Nothing else.
<quote>It looks like those client have no option at all but to buy the 20 License package. And guess what you can't buy new PCs with Office 2003, so what does that mean? ...</quote>
I agree that this link could be seen as unfortunate by some. However, on the other hand, given what these new PCs produce in cost for your 10+ user business (i.e. think total operational IT cost in such organisation), the price you'd need to pay for the Scalix product if this was really what you need would be so little compared to other components that I find that quite easy to justify.
The fact that Microsoft opts to no longer ship an older version of their product, resulting in quite broad and fundamental change in presumably quite unrelated areas of their customers infrastructure highlights the risks of lock-in, stickiness and cross-selling associated with the use of a single vendor's products, especially when that vendor is not committed to open standards and interfaces.
IMHO, this truely highlights the strong need to consider client-side alternatives as well and we'll continue to help keeping that door open now and going forward.
Florian.
Florian von Kurnatowski, Die Harder!
Who is online
Users browsing this forum: No registered users and 2 guests