Re: [Ledger-smb-devel] Last technical issue for 1.5-rc1 -- RFC

[David G]

  
  
Hi Erik, Chris,

Once again, as we've discussed on IRC, I think that separating our
templating for UI and doc generation makes sense, sticking to TT for
doc generation for now, and moving as rapidly as possible to Dojo
for the UI which I believe we are well on the way to achieving.
 
Once all of the UI has been switched to Dojo, I'd suggest we revisit
our requirements for Doc generation, at that time it may be viable
to either alter our used featureset of TT to be compatible with
Text::Xslate, or work with the Xslate devs to extend it to cover our
needs as well.

Regards
David G

On 08/05/16 00:28, Chris Travers wrote:


  

  On Thu, May 5, 2016 at 10:17 AM, Erik
Huelsmann 
wrote:

  

  

  
Hi all,
  

The last technical issue that we have left for
1.5-rc1 in the issue tracker is #854 (https://github.com/ledgersmb/LedgerSMB/issues/854):

Included templates not loaded from the database.

  
  Now, I think I can fix this issue - and probably
  reduce overall code complexity of the template
  processor and more, however, that would require
  tying our template library more strongly with
  Template::Toolkit (TT).
  

In the past, we have talked about replacing TT
because it might not be fast enough. So, before I
embark on tying our code deeper into TT, this is a
question that begs to be answered: Do we really want
to go that way?

  
  Assuming we need a templating engine for years to
  come, I looked for other templating engines. This is
  not easy, because we have a lot vested in templates
  running on TT. One that stands out is Text::Xslate,
  because it has a mode where it accepts - according to
  its own docs - a lot of TT code. On closer
  investigation, it seems that this isn't true, because
  we use alternate delimiters ""
  instead of TT's default "[%" and "%]". So, this
  advantage doesn't seem to apply. Text::Xslate is said
  to be very fast though -- one of the properties we are
  to be looking for [1][2].

  


  


Then again, if we're going to be using Dojo widgets more
and more, we'll be able to use the Dojo template engine
to build the page client side. If that's the case, then
do we - long term - still need a (blazingly fast) server
side template engine? (There's an issue about this with
a question from me regarding our payments screen: https://github.com/ledgersmb/LedgerSMB/issues/1077
).

  

  

  

  My question comes from the fact that
I'd expect us to use dynamic page
techniques that dojo's dgrid employs to
do scrolling without building the full
page. Instead, it builds only the
visible part of the page. All this based
on web services which can serve result
ranges.
  

  

  

  

  



My thinking on this is that I think this is exactly the
  right question.   My thinking is that the logical
  strategic direction is for us to move in the direction of
  more dojo widgets, more services, and hence more
  client-side templates and less server-side templates.
  

This means that we still need templates for generating
  HTML/PDF/etc docs where we need to do this (financial
  statements, invoices, etc) but not for general use of the
  system.  I don't see TT as 

Re: [Ledger-smb-devel] ledgersmb.org traffic analysis & SourceForge AddOns repository

[David G]

  
  
Hi Erik,

I'd say yes, lets move them to GitHub, and each addon in a separate
repository, but not owned by the ledgersmb github user.
Instead lets create a ledgersmb-addons user and home each addon
under that

This allows a couple of benefits, especially as the number of
contributors/developers increases.
eg: different people may need to have admin rights for each
repository.
    It may be possible to install addons by simply running a
bin/addon-install $addon-name from within the lsmb install dir.
    that script could essentially do 
        git clone github.com/ledgersmb-addon/$addon-name &&
cd $addon-name && ./install
    It could also be run with no arguments at which time it presents
a list of available addon's and the first line of each addon's
readme.

Some of this would be harder (but not impossible) if we homed them
under the ledgersmb user or kept them in a single repo
Doing a "git pull" to update an addon wouldn't be trivial if there
were multiple addons in a single repo as you would get them all
updated at the same time.

Regards
David G

On 07/05/16 18:10, Erik Huelsmann
  wrote:


  

  

  

  Hi all,


  
  Over the years, a number of AddOns have been developed
  for LedgerSMB 1.3. These are stored at SourceForge in
  the AddOns repository.  These probably haven't been
  updated enough to be applicable to 1.4.
  

Now, why do I start about this? I'm wondering if we
should move these to GitHub (and if so, how). The thing
being: of the 600 hits on the features page in April,
50%(!) went to check the add-ons repository.

  
  That suggests 2 things, I'd say:

 (1) It seems like we have a hidden treasure here: I wasn't
aware it could be as important to peolpe as it apparently is
to have (the right) add-ons
  
   (2) Currently these add-ons haven't been moved to GitHub -
  left on SourceForge for reference and getting stale
  
  

Should we move the add-ons to GitHub?

If so: How? Each add-on its own repository? All Add-ons in
  a single repository?






  

  

  
-- 
  
Bye,
  
  
  Erik.
  
  
  http://efficito.com --
Hosted accounting and ERP.
  Robust and Flexible. No vendor lock-in.

  

  

  

  

  
  
  
  
  --
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
  
  
  
  ___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel



  


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] (Switching to) "cpanfile" to declare dependencies for 'cpanm'?

[David G]

  
  
Hi Erik,

From our previous discussions on IRC I think this is the only
sensible way to go.

David G

On 07/05/16 23:33, Erik Huelsmann
  wrote:


  

  

  

  
  
  As I'm writing the installation instructions for 1.5,
  I have David's reaction to Marjan in the back of my
  head where my advise to use ```cpanm``` to install the
  dependencies for LedgerSMB works a bit too well,
  pulling in all the dependencies we added for our BDD
  testing framework.
  

My thinking is that - if we want testing on users
systems *at all* - we want just only minimal tests being
run on our users systems. So, I'd like to declare most
of our test dependencies to be "development tools"
(development dependencies).

  
  The MakeMaker format doesn't seem to have a facility to do
  that.
  

But cpanfile *does* have a facility to do that *and*
```cpanm``` has support for 'cpanfile'. What's more,
anything declared as "development dependency" will be
skipped for installation unless explicitly requested.

  
  I'm thinking cpanfile is much more the tool we need than
  MakeMaker?
  

The fact that CPAN doesn't support cpanfile is not a problem:
out of 10 years of existence in the project, we've never
distributed through CPAN...

  

  

  

  -- 
  
Bye,
  
  
  Erik.
  
  
  http://efficito.com --
Hosted accounting and ERP.
  Robust and Flexible. No vendor lock-in.

  

  

  

  

  
  
  
  
  --
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
  
  
  
  ___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel



  


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Questions due to writing 1.5 installation instructions: "standalone" / "TeX::Encode" / REST ?

[Erik Huelsmann]

Hi all,


Due to trying to write a comprehensive list of instructions people should
run to install LedgerSMB 1.5, I now have a number of questions:

1. Our Makefile.PL lists CGI::Emulate::PSGI as a dependency under the
Starman server. It's my perception though that in order to run 1.5, you
need Plack, Plack::Builder, Plack::Middleware::Static and
CGI::Emulate::PSGI. *Always*. Then, if you want to run "stand alone", you
can install Starman. But the other 4 aren't optional. Am I right? I mean,
we don't support "pure CGI" anymore... But if not through Plack, then how?

2. Makefile.PL lists "TeX::Encode" both as a core requirement as well as a
feature requirement for LaTeX. I'd think this really is *only* for
LaTeX/PDF?

3. What is the status of our "RESTful Web Services XML support"? It's
listed as a feature, but does it work? Has it ever worked? Are we actively
advertizing this feature's availability?


Regards,

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Last technical issue for 1.5-rc1 -- RFC

[Erik Huelsmann]

>
>
>> Then again, if we're going to be using Dojo widgets more and more, we'll
>> be able to use the Dojo template engine to build the page client side. If
>> that's the case, then do we - long term - still need a (blazingly fast)
>> server side template engine? (There's an issue about this with a question
>> from me regarding our payments screen:
>> https://github.com/ledgersmb/LedgerSMB/issues/1077 ).
>> My question comes from the fact that I'd expect us to use dynamic page
>> techniques that dojo's dgrid employs to do scrolling without building the
>> full page. Instead, it builds only the visible part of the page. All this
>> based on web services which can serve result ranges.
>>
>
> My thinking on this is that I think this is exactly the right question.
> My thinking is that the logical strategic direction is for us to move in
> the direction of more dojo widgets, more services, and hence more
> client-side templates and less server-side templates.
>
> This means that we still need templates for generating HTML/PDF/etc docs
> where we need to do this (financial statements, invoices, etc) but not for
> general use of the system.  I don't see TT as having a major performance
> problem at that point.
>

Ok. That's clear. Then my conclusion is that I'll work to further integrate
with TT for the purpose of output document generation and - for 1.6 - have
UI template rendering separated (at the API level) from output document
rendering. Specifically to support this difference:


> **Note** that the use of a high-performance templating engine serves a
>> different purpose in our application than the templating engine which needs
>> to support loading INCLUDEs from the database: the former is to handle our
>> UI generation, the latter supports the generation of "document output"
>> (invoices, packing lists, etc).
>>
>

> agreed
>

Ok. Then I'll start working the issue with the above in mind.

Regards,

Erik.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Changes to the ledgersmb.org website

[John Locke]

(resend from my subscribed email address...)

Hi,

I've made the following changes:

* Allowed much bigger user pictures to upload, but set a server-side 
preset (the unused Square Thumbnail) to resize user pictures to 44x44, 
which is what 4em generated in Chrome)
* Turned on "Panelizer" and applied to article teasers -- with no 
further configuration, this removed the authoring info on the teasers
* Set up a Visual Regression Testing tool (but did the baseline at this 
point, after making the previous changes)
* Applied the two remaining CSS fixes from Erik: making the user image 
"display: inline-block" and giving them 4px rounded corners


* Ran the visual regression testing, you can see the results here: 
http://ledgersmb.org/lsmb_shots/gallery.html


Regarding best practices, I think we already have a view of content that 
takes a tag name from the path to filter, so you probably didn't need to 
create that. http://ledgersmb.org/topic/installation ... it looks like 
your view filters down to only articles, so it shows less -- no harm 
having that here, especially if you want to curate further...


Cheers,
John


On 05/07/2016 05:30 AM, Erik Huelsmann wrote:

Hi John,


In preparation of the 1.5 release, I've been looking at ways to 
publish installation instructions and notes. While doing so, I found 
that there wasn't really a structure for showing installation 
instructions on the ledgersmb.org  site. Under 
the Documentation menu item in the Main menu, there's now an 
"Installation" link which points to http://ledgersmb.org/installation. 
It's a new view I created by collecting all contents of type "Article" 
with the tag "Installation".


Would you say that that's the right way to go? Or should I have 
created a separate content type? I'm thinking that may be overkill.


One thing that I've noted and never brought up before: I think the 
"user picture" on each article is *way* too big. It takes up a lot of 
valuable screen estate. Can we do away with it in the teaser layout, 
only showing the textual submission data (user and date)? Then maybe 
shrink the image to 4ems-width max, with the submission data on the 
right of it, instead of on the next row? (Saves some vertical more 
screen estate.)


In my browser I added two rules to achieve the bit of the user picture 
in the regular ("Content") view:


.user-picture img {
width: 4em;
}
.user-picture {
display: inline-block;
}


I was able to achieve the bit I mean about the teaser section with 
this rule:


.node-teaser .meta.submitted img {
display: none;
border-radius: 3px;   // the pictures look a lot more friendly 
when I add that

}

I hope you all agree this step makes the site's content much more 
accessible; an improvement.


Could you put these into effect?



--
Bye,

Erik.

http://efficito.com  -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Last technical issue for 1.5-rc1 -- RFC

[Chris Travers]

On Thu, May 5, 2016 at 10:17 AM, Erik Huelsmann  wrote:

> Hi all,
>
> The last technical issue that we have left for 1.5-rc1 in the issue
> tracker is #854 (https://github.com/ledgersmb/LedgerSMB/issues/854):
> Included templates not loaded from the database.
>
> Now, I think I can fix this issue - and probably reduce overall code
> complexity of the template processor and more, however, that would require
> tying our template library more strongly with Template::Toolkit (TT).
>
> In the past, we have talked about replacing TT because it might not be
> fast enough. So, before I embark on tying our code deeper into TT, this is
> a question that begs to be answered: Do we really want to go that way?
>
> Assuming we need a templating engine for years to come, I looked for other
> templating engines. This is not easy, because we have a lot vested in
> templates running on TT. One that stands out is Text::Xslate, because it
> has a mode where it accepts - according to its own docs - a lot of TT code.
> On closer investigation, it seems that this isn't true, because we use
> alternate delimiters "" instead of TT's default "[%" and
> "%]". So, this advantage doesn't seem to apply. Text::Xslate is said to be
> very fast though -- one of the properties we are to be looking for [1][2].
>

> Then again, if we're going to be using Dojo widgets more and more, we'll
> be able to use the Dojo template engine to build the page client side. If
> that's the case, then do we - long term - still need a (blazingly fast)
> server side template engine? (There's an issue about this with a question
> from me regarding our payments screen:
> https://github.com/ledgersmb/LedgerSMB/issues/1077 ).
> My question comes from the fact that I'd expect us to use dynamic page
> techniques that dojo's dgrid employs to do scrolling without building the
> full page. Instead, it builds only the visible part of the page. All this
> based on web services which can serve result ranges.
>

My thinking on this is that I think this is exactly the right question.
My thinking is that the logical strategic direction is for us to move in
the direction of more dojo widgets, more services, and hence more
client-side templates and less server-side templates.

This means that we still need templates for generating HTML/PDF/etc docs
where we need to do this (financial statements, invoices, etc) but not for
general use of the system.  I don't see TT as having a major performance
problem at that point.

>
>
> **Note** that the use of a high-performance templating engine serves a
> different purpose in our application than the templating engine which needs
> to support loading INCLUDEs from the database: the former is to handle our
> UI generation, the latter supports the generation of "document output"
> (invoices, packing lists, etc).
>


agreed

>
> We might decide that it's fine to stick with TT for the purpose of our
> "document output" while we want to keep the option open to switch to
> another template processor for our UI generation. If that's the decision we
> reach, then I guess it's fine for me to start using more of TT's features
> with our template engine to solve issue #854.
>
>
> Comments?
>
>
> [1] https://metacpan.org/pod/Text::Xslate#High-performance
> [2] I'm not sure if the comparison uses TT's feature of "compiled
> templates" which LedgerSMB can use -- this basically eliminates the need to
> parse a template more than once.
>
> --
> Bye,
>
> Erik.
>
> http://efficito.com -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
>



-- 
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor
lock-in.
http://www.efficito.com/learn_more
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] (Switching to) "cpanfile" to declare dependencies for 'cpanm'?

[Erik Huelsmann]

As I'm writing the installation instructions for 1.5, I have David's
reaction to Marjan in the back of my head where my advise to use
```cpanm``` to install the dependencies for LedgerSMB works a bit too well,
pulling in all the dependencies we added for our BDD testing framework.

My thinking is that - if we want testing on users systems *at all* - we
want just only minimal tests being run on our users systems. So, I'd like
to declare most of our test dependencies to be "development tools"
(development dependencies).

The MakeMaker format doesn't seem to have a facility to do that.

But cpanfile *does* have a facility to do that *and* ```cpanm``` has
support for 'cpanfile'. What's more, anything declared as "development
dependency" will be skipped for installation unless explicitly requested.

I'm thinking cpanfile is much more the tool we need than MakeMaker?

The fact that CPAN doesn't support cpanfile is not a problem: out of 10
years of existence in the project, we've never distributed through CPAN...

-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Changes to the ledgersmb.org website

[Erik Huelsmann]

Hi John,


In preparation of the 1.5 release, I've been looking at ways to publish
installation instructions and notes. While doing so, I found that there
wasn't really a structure for showing installation instructions on the
ledgersmb.org site. Under the Documentation menu item in the Main menu,
there's now an "Installation" link which points to
http://ledgersmb.org/installation. It's a new view I created by collecting
all contents of type "Article" with the tag "Installation".

Would you say that that's the right way to go? Or should I have created a
separate content type? I'm thinking that may be overkill.

One thing that I've noted and never brought up before: I think the "user
picture" on each article is *way* too big. It takes up a lot of valuable
screen estate. Can we do away with it in the teaser layout, only showing
the textual submission data (user and date)? Then maybe shrink the image to
4ems-width max, with the submission data on the right of it, instead of on
the next row? (Saves some vertical more screen estate.)

In my browser I added two rules to achieve the bit of the user picture in
the regular ("Content") view:

.user-picture img {
width: 4em;
}
.user-picture {
display: inline-block;
}


I was able to achieve the bit I mean about the teaser section with this
rule:

.node-teaser .meta.submitted img {
display: none;
border-radius: 3px;   // the pictures look a lot more friendly when I
add that
}

I hope you all agree this step makes the site's content much more
accessible; an improvement.

Could you put these into effect?



-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] ledgersmb.org traffic analysis & SourceForge AddOns repository

[Erik Huelsmann]

Hi all,


Over the years, a number of AddOns have been developed for LedgerSMB 1.3.
These are stored at SourceForge in the AddOns repository.  These probably
haven't been updated enough to be applicable to 1.4.

Now, why do I start about this? I'm wondering if we should move these to
GitHub (and if so, how). The thing being: of the 600 hits on the features
page in April, 50%(!) went to check the add-ons repository.

That suggests 2 things, I'd say:
 (1) It seems like we have a hidden treasure here: I wasn't aware it could
be as important to peolpe as it apparently is to have (the right) add-ons
 (2) Currently these add-ons haven't been moved to GitHub - left on
SourceForge for reference and getting stale


Should we move the add-ons to GitHub?
If so: How? Each add-on its own repository? All Add-ons in a single
repository?


-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Preparing 1.5-rc1 documentation / analysing where to put the various docs

[Erik Huelsmann]

Before starting to write the various docs, while thinking where to put
them, I decided to have a look at our webtraffic (made available by our
Drupal hoster Freelock.com: http://piwik.freelock.com/).

In April, nearly 60% of our traffic entered the site through the front
page. Funny fact: of the remaining 40%, nearly all traffic enters the site
at one specific FAQ item: "What's the difference between a sales order and
a sales invoice".

Out of total traffic on the front page, 20% goes straight to download, 20%
goes to inspect the features page and 20% goes to the demo page. Only 6%
goes to the documentation pages.


Would it be a valid conclusion that apparently the website isn't a good
place to write our documentation?

Or would a better conclusion be that we're apparently not referring to any
existing documentation on the site from sources that people have access to?


I can imagine both to be the case, really. In order to be able to take the
next step the above leaves me wondering: if we put summarized installation
instructions in the release package and more extensive ones on the site, we
can adjust the installation instructions after the release -- e.g. based on
user experience. I like that idea a lot.


In a way, I'm feeling like I'm designing/architecting again :-) This time
our information structure. So, I'd *love* to get some feedback on this
topic.

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel